Re: [ccp4bb] buccaneer_pipeline failure (ccp4 6.2.0)

[Tim Gruene]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Frank,

it may not be the python binary itself but the PYTHONPATH which is
incorrectly set. After initialising ccp4, mine reads
tg@slartibartfast:~$ echo $PYTHONPATH
/xtal/Suites/CCP4/ccp4-6.2.0/share/python:
which is modified around line 231 in $CBIN/include/ccp4.setup

My python binary is /usr/bin/python, and I have used buccaneer without
errors.

Tim



On 10/17/2011 09:30 PM, Frank von Delft wrote:
> Hi, we got around to switching to ccp4 version 6.2.0, but now buccaneer
> fails from the GUI.  Below is what shows up if you view the com file
> before execution; and below that the logfile.
> 
> Seems to me it's using the wrong python executable;  the first one on my
> path is certainly nothing to do with ccp4, so now wonder it can't import.
> 
> Shouldn't python be invoked explicitly with its full path?  Where can I
> set this?  (Mind you, setting it in the Run&View didn't work.)
> Cheers
> phx
> 
> 
> 
> 
> *Run&View Com File: *
> python -u /usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline -stdin
> 
> 
> *Logfile*
> #CCP4I VERSION CCP4Interface 2.1.0
> #CCP4I SCRIPT LOG buccaneer_pipeline
> #CCP4I DATE 17 Oct 2011  18:45:20
> #CCP4I USER loretta
> #CCP4I PROJECT PROJECT
> #CCP4I JOB_ID 13
> #CCP4I SCRATCH /tmp/loretta
> #CCP4I HOSTNAME hestia.sgc.ox.ac.uk
> #CCP4I PID 13684
> 
> ***
> * Information from CCP4Interface script
> ***
> The program run with command: python -u
> /usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline -stdin
> has failed with error message
> Traceback (most recent call last):
>   File "/usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline", line
> 3, in 
> from CCP4pipeline import Control
> ImportError: No module named CCP4pipeline
> ***
> 
> 

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

GPG Key ID = A46BEE1A

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOnSz+UxlJ7aRr7hoRAvmXAJ4uDTlGMIRPGR99h7fR4oeBIytb/wCfcfMP
09DpVoL70bWQMpG9wEKMEmc=
=atc8
-END PGP SIGNATURE-

Re: [ccp4bb] MR - small coiled coil, 1.65A = 1.000 solutions, all of them wrong

[M T]

Dear Napoleão, we solved this type of problem in a paper of 2004 (J. Mol.
Biol. (2004) 342, 275–287) with the using of EPMR which use a evolutionary
search algorithm, I will send you the paper later. It was 36aa dimeric
coiled-coil and we had a lot of molecular replacement problems with other
tested molecular replacement programs.

http://www.epmr.info/UsersGuide.html

Good luck.

Re: [ccp4bb] MR - small coiled coil, 1.65A = 1.000 solutions, all of them wrong

[Vellieux Frederic]

Just to add to what has been "said" (written) before:

coiled coiled or simply helices can be very problematic for M.R.. Human 
sacrifice has never given any positive result (as reported in the 
literature as far as I know), but "heavy atom sacrifice" could be 
attempted ("heavy atom" includes in my view atoms that are used for SAD, 
MAD - such as S, Se... - in addition to Au, Pt...) in parallel to your 
M.R. searches which may never provide you with an acceptable solution.


Fred.

Napoleão Valadares wrote:

Hi there!
I got crystals from some synthetic peptides I bought, they are 30 
residues long and are supposed to form a coiled coil. I collected 
various data sets (home source, Brookhaven and Diamond), including 
some at the resolution of 1.65 A, for which the space group appears to 
be C222 or C2221. The unit cell is small, 22.67, 88.06, 26.13, and the 
Matheus Coefficient indicates that's there's only one helix in the 
asymmetric unit and a 25% solvent content.


I have tried A LOT of Molecular Replacement using Phaser and 
Phenix AutoMR. I'm using a 80% identity coiled coil helix as search 
model. The programs give me solutions with "reasonable" maps, but it 
is never possible to refine to achieve Rvalues below 0.40. 
Additionally, maps from different solutions look reasonable, so I'm 
thinking these are all bias.


I have 5 other synthetic 30 residues peptides (that crystallize in 
different space groups and diffract to lower resolutions), including a 
SelenoMethionine (SM) derivative (but it does not have enough 
anomalous signal, ASU is too big, it is possible that the SM are 
disordered). I'm stuck on this since March.


Regarding the search model, I already tried trimming some or all 
side chains and removing 2, 3 or 5 residues on each/both sides. I also 
tried other search models. Maybe some "magic" combination of 
parameters on Phaser or other programs can help me.


What is your advice regarding how to proceed with MR? Is there 
some program, procedure, parameter, pray or human sacrifice that could 
help me?

Thank you.
Regards,
  Napo

Re: [ccp4bb] IUCr committees, depositing images

[John R Helliwell]

Dear Colleagues,
Following on from my posting to the CCP4bb of yesterday an IUCr Forum
has been set up for Public input on the diffraction data deposition
future. Thus this Forum will record an organised set of inputs for
future reference. Instructions on how to register at this Forum can be
found there:-

http://forums.iucr.org/index.php?sid=4e83bcc36ec972f5bed1508d5bb7c05a

 and/or via Brian McMahon (b...@iucr.org) in case of difficulty.

As further background information you will find at the Forum the IUCr
Diffraction Data Deposition Working Group Terms of Reference, the
Minutes of the IUCr Madrid Congress inaugural meeting and a paper from
the Commission on Biological Macromolecules (lead author Tom
Terwilliger) .

We look forward to your inputs to the Forum.

Best wishes,
John
Prof John R Helliwell DSc
Chairman of the IUCr Diffraction Data Deposition Working Group (IUCr DDDWG)



On Mon, Oct 17, 2011 at 7:52 AM, Artem Evdokimov
 wrote:
> We overestimate the value of individual structures because we're human :)
>
> If a problem is important enough that one structure makes or breaks the
> case, a sensible thing to do would be to get more structures and strive to
> obtain some other flavor of pertinent information by methods that are
> unlikely to suffer from the same bias as structures.
>
> Objectivity of the experimenter is key.
> I personally would love to see the development of computationally objective
> (i.e. human-free) methods for integrating various kinds of scientific data.
> If we could escape from the brain shackles imposed on us by our
> crunchy-primate ancestors that'd be very nice, since we rarely need to worry
> about quickly counting members of our primate pod (was Cousin Mo eaten by a
> tiger last night, and is the tiger now full), or to make split-second
> decisions regarding striped creepers swinging down from branches (is it a
> hidden leopard, a deadly Striped Death viper, or a harmless vine?) -- but
> these instinctive modes of thought seriously mess up our collective ability
> to perform complex science.
>
> Artem
>
> On Mon, Oct 17, 2011 at 12:14 AM, Frank von Delft
>  wrote:
>>
>> On 17/10/2011 01:52, Wladek Minor wrote:
>>
>> Frank,
>>
>> This is serious problem for biologists. There is a structure with ligand.
>> The same data were re-interpreted and people did not find the ligand. This
>> re-interpretation is not really valid until we will look into diffraction
>> data. Biologist lost tremendous amount of time and effort looking into
>> interfratation and ...
>>
>> NOw this is very important biomedical structure.
>>
>> Yes I know and agree partially.
>>
>> That said:  I reckon we vastly overestimate the value of individual
>> structures;  it's the ensemble that is informative.  A decade from now,
>> depositing a single structure of a protein will be seen to be as just as
>> silly as it is currently not to deposit structure factors.
>>
>> Including those "very important biomedical structures".  Those things tend
>> to become suddenly "important" (in the grand scheme) only after the ligand's
>> biological/clinical effects could be demonstrated.  And even then the
>> structure itself is only important if it helps a chemist.
>>
>> If this sounds extreme:  consider how much other data it now takes to get
>> structures into nature/science/cell.  Or what happened (or rather didn't) to
>> all those patents on structures that were such a big deal a decade ago.
>>
>> phx.
>>
>>
>>
>> Wladek
>>
>>
>> At 02:59 PM 10/16/2011, you wrote:
>>
>> One other question (for both key issues described):  what exactly is the
>> problem the committees are aiming to address?
>>
>> Because I can't help noticing that Tom's email did not spark an on-list
>> discussion;  do people actually feel either are issues?  Isn't the more
>> burning problem how best to use the 10,000s of structures we're churning
>> out?  In the grand scheme of things, they're pretty inaccurate anyway:
>> static snapshots of crippled fragments of proteins far from their many
>> interaction partners.  So do we need 100,000s of structures instead?  If so,
>> we may soon (collectively) stop being able to care about the original
>> dataset or how to reproduce analysis number 2238 from 2 years ago.
>>
>> (No, I'm not convinced this question is relevant only to structural
>> genomics.)
>>
>> phx.
>>
>>
>>
>> On 16/10/2011 19:38, Frank von Delft wrote:
>>
>> On the deposition of raw data:
>>
>> I recommend to the committee that before it convenes again, every member
>> should go collect some data on a beamline with a Pilatus detector [feel free
>> to join us at Diamond].  Because by the probable time any recommendations
>> actually emerge, most beamlines will have one of those (or similar), we'll
>> be generating more data than the LHC, and users will be happy just to have
>> it integrated, never mind worry about its fate.
>>
>> That's not an endorsement, btw, just an observation/prediction.
>>
>> phx.
>>
>>
>>
>>
>> On 14/10/2011 23:56, 

[ccp4bb] Dennis Ritchie

[Miguel Ortiz Lombardía]

Hi community,

I have been waiting for someone more knowledgeable to write about the
passing away of Dennis Ritchie (8 October) especially after the recent
obituaries posted in the list. I confess I know little about him, except:

1/ He created the C language ( and together with Brian Kernighan wrote
an extremely useful book about it )
2/ He and Ken Thompson were key in the development of something called
UNIX...

Undoubtedly, he made an impact in our field.


-- 
Miguel

Architecture et Fonction des Macromolécules Biologiques (UMR6098)
CNRS, Universités d'Aix-Marseille I & II
Case 932, 163 Avenue de Luminy, 13288 Marseille cedex 9, France
Tel: +33(0) 491 82 55 93
Fax: +33(0) 491 26 67 20
mailto:miguel.ortiz-lombar...@afmb.univ-mrs.fr
http://www.afmb.univ-mrs.fr/Miguel-Ortiz-Lombardia

[ccp4bb] Head of Crystallography, Vertex

[David Waterman]

Posted on behalf of Vertex Pharmaceuticals (please do not reply directly to
me!)

Link for applicants:
http://bs.serving-sys.com/BurstingPipe/adServer.bs?cn=tf&c=20&mc=click&pli=3398538&PluID=0&ord=[timestamp
]

Head of Crystallography

 Oxfordshire



Vertex creates new possibilities in medicine. Our team discovers, develops
and commercializes innovative therapies so people with serious diseases can
lead better lives. Vertex scientists and our collaborators are working on
new medicines to cure or significantly advance the treatment of hepatitis C,
cystic fibrosis, epilepsy and other life-threatening diseases. Founded more
than 20 years ago in Cambridge, MA, we now have ongoing worldwide research
programs and sites in the United States, United Kingdom and Canada.* *Vertex
has consistently been recognized as one of the industry's top workplaces by
leading publications such as the *Boston Globe*, *Boston Business Journal*,
*San Diego Business Journal* and *The Scientist*, and most recently was
named the top employer in *Science* magazine's 2011 annual survey.

As the UK-based subsidiary, Vertex Pharmaceuticals (Europe) Ltd brings
together scientists from various disciplines and backgrounds to form a
highly creative and productive team that works on finding medicines for the
treatment of cancer and inflammatory diseases. Our new research facility in
Oxfordshire is equipped with the latest technology that enables us to tackle
all aspects of early phase small molecule drug discovery and, with the help
of the wider organization, take on some of the most ambitious goals in the
industry.

Structure based drug design, has enabled all our major achievements so far.
It is our intention that this technology will continue to play a central
role in the way we do drug discovery. The close proximity of the Diamond
Light Source makes the UK site particularly important in this field of
Vertex research. The now vacant job of Head of Crystallography is therefore
wonderful career opportunity for someone with skills in structural biology
and a desire to make important new drugs.



You are most likely to have a PhD and extensive experience in protein
crystallography. Strong leadership skills are required and excellent written
and oral publication record is a must. Experience with pharma-biased
methodologies such as fragment-based lead generation and the ability to
rapidly assess and introduce novel technologies would be an advantage. The
Head of Crystallography will be expected to influence Vertex research on
both sides of the Atlantic within the structural biology groups and also by
providing ideas and impetus for new projects. In order to do this,
communication skills and the ability to work in collaboration must be first
rate. An interest in biological and chemical science beyond structural
biology would be most useful since this would allow the candidate to take
career opportunities in multi disciplinary project leadership.



If you are innovative and focussed on achieving success within a
collaborative environment, please visit our website www.vrtx.com to find out
more information and apply.



The Science of Possibility.



Closing date for applications is 7th November 2011.


Head of Crystallography - web advert - 12.10.11.doc
Description: MS-Word document

Re: [ccp4bb] Dennis Ritchie

[Tim Gruene]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Miguel,

There are a couple of well-written obituaries:
http://www.wired.com/wiredenterprise/2011/10/dennis-ritchie/
http://edition.cnn.com/2011/10/14/tech/innovation/dennis-ritchie-obit-bell-labs/


To acknowledge his work, you might start you list counting from 0 rather
than 1 and swap the two items, because C was developed since Fortran did
not match the requirements to develop an OS like UNIX.

Tim

On 10/18/2011 10:58 AM, Miguel Ortiz Lombardía wrote:
> Hi community,
> 
> I have been waiting for someone more knowledgeable to write about the
> passing away of Dennis Ritchie (8 October) especially after the recent
> obituaries posted in the list. I confess I know little about him, except:
> 
> 1/ He created the C language ( and together with Brian Kernighan wrote
> an extremely useful book about it )
> 2/ He and Ken Thompson were key in the development of something called
> UNIX...
> 
> Undoubtedly, he made an impact in our field.
> 
> 

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

GPG Key ID = A46BEE1A

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOnUcvUxlJ7aRr7hoRAhSpAKDugWVs7GKzzwGsQM4o63TQ8FT01ACglBKO
G4MkaWrHO6qSTJyrNhmlXeY=
=jWbu
-END PGP SIGNATURE-

Re: [ccp4bb] buccaneer_pipeline failure (ccp4 6.2.0)

[Frank von Delft]

Mine reads:
/usr/local/ccp4/6.2.0/ccp4-6.2.0/share/python:/usr/local/ccpnmr/ccpnmr1.0/python

That should work, right?  Where else can I look, for the failing 
import?  This is a lettuce-fresh install, pulled straight off web and 
installed with all defaults.


Cheers
phx.


On 18/10/2011 08:38, Tim Gruene wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Frank,

it may not be the python binary itself but the PYTHONPATH which is
incorrectly set. After initialising ccp4, mine reads
tg@slartibartfast:~$ echo $PYTHONPATH
/xtal/Suites/CCP4/ccp4-6.2.0/share/python:
which is modified around line 231 in $CBIN/include/ccp4.setup

My python binary is /usr/bin/python, and I have used buccaneer without
errors.

Tim



On 10/17/2011 09:30 PM, Frank von Delft wrote:

Hi, we got around to switching to ccp4 version 6.2.0, but now buccaneer
fails from the GUI.  Below is what shows up if you view the com file
before execution; and below that the logfile.

Seems to me it's using the wrong python executable;  the first one on my
path is certainly nothing to do with ccp4, so now wonder it can't import.

Shouldn't python be invoked explicitly with its full path?  Where can I
set this?  (Mind you, setting it in the Run&View didn't work.)
Cheers
phx




*Run&View Com File: *
python -u /usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline -stdin


*Logfile*
#CCP4I VERSION CCP4Interface 2.1.0
#CCP4I SCRIPT LOG buccaneer_pipeline
#CCP4I DATE 17 Oct 2011  18:45:20
#CCP4I USER loretta
#CCP4I PROJECT PROJECT
#CCP4I JOB_ID 13
#CCP4I SCRATCH /tmp/loretta
#CCP4I HOSTNAME hestia.sgc.ox.ac.uk
#CCP4I PID 13684

***
* Information from CCP4Interface script
***
The program run with command: python -u
/usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline -stdin
has failed with error message
Traceback (most recent call last):
   File "/usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline", line
3, in
 from CCP4pipeline import Control
ImportError: No module named CCP4pipeline
***


- -- 
- --

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

GPG Key ID = A46BEE1A

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOnSz+UxlJ7aRr7hoRAvmXAJ4uDTlGMIRPGR99h7fR4oeBIytb/wCfcfMP
09DpVoL70bWQMpG9wEKMEmc=
=atc8
-END PGP SIGNATURE-

Re: [ccp4bb] buccaneer_pipeline failure (ccp4 6.2.0)

[Tim Gruene]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

And you do have read access to
/usr/local/ccp4/6.2.0/ccp4-6.2.0/share/python/CCP4pipeline.py
(on our installation, the mode is actually 755, but I suppose 644 should
be sufficient).
You can set PYTHONVERBOSE to 1 or higher in the shell you start ccp4i
from to see what python is doing ('man python').

Tim

On 10/18/2011 11:34 AM, Frank von Delft wrote:
> Mine reads:
> /usr/local/ccp4/6.2.0/ccp4-6.2.0/share/python:/usr/local/ccpnmr/ccpnmr1.0/python
> 
> 
> That should work, right?  Where else can I look, for the failing
> import?  This is a lettuce-fresh install, pulled straight off web and
> installed with all defaults.
> 
> Cheers
> phx.
> 
> 
> On 18/10/2011 08:38, Tim Gruene wrote:
> Hi Frank,
> 
> it may not be the python binary itself but the PYTHONPATH which is
> incorrectly set. After initialising ccp4, mine reads
> tg@slartibartfast:~$ echo $PYTHONPATH
> /xtal/Suites/CCP4/ccp4-6.2.0/share/python:
> which is modified around line 231 in $CBIN/include/ccp4.setup
> 
> My python binary is /usr/bin/python, and I have used buccaneer without
> errors.
> 
> Tim
> 
> 
> 
> On 10/17/2011 09:30 PM, Frank von Delft wrote:
 Hi, we got around to switching to ccp4 version 6.2.0, but now buccaneer
 fails from the GUI.  Below is what shows up if you view the com file
 before execution; and below that the logfile.

 Seems to me it's using the wrong python executable;  the first one on my
 path is certainly nothing to do with ccp4, so now wonder it can't
 import.

 Shouldn't python be invoked explicitly with its full path?  Where can I
 set this?  (Mind you, setting it in the Run&View didn't work.)
 Cheers
 phx




 *Run&View Com File: *
 python -u /usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline -stdin


 *Logfile*
 #CCP4I VERSION CCP4Interface 2.1.0
 #CCP4I SCRIPT LOG buccaneer_pipeline
 #CCP4I DATE 17 Oct 2011  18:45:20
 #CCP4I USER loretta
 #CCP4I PROJECT PROJECT
 #CCP4I JOB_ID 13
 #CCP4I SCRATCH /tmp/loretta
 #CCP4I HOSTNAME hestia.sgc.ox.ac.uk
 #CCP4I PID 13684

 ***

 * Information from CCP4Interface script
 ***

 The program run with command: python -u
 /usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline -stdin
 has failed with error message
 Traceback (most recent call last):
File "/usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline", line
 3, in
  from CCP4pipeline import Control
 ImportError: No module named CCP4pipeline
 ***



> -- - --
> Dr Tim Gruene
> Institut fuer anorganische Chemie
> Tammannstr. 4
> D-37077 Goettingen
> 
> GPG Key ID = A46BEE1A
> 

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

GPG Key ID = A46BEE1A

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOnUw9UxlJ7aRr7hoRAiREAKCgr2dJMVtNPi4BZKnzMqoJw5O/GwCgw1Pb
XrR2jUbn0oGsPL6W+PdyGiA=
=BS9b
-END PGP SIGNATURE-

[ccp4bb] IUCr discussion forum on diffraction data deposition

[Brian McMahon]

Thanks to John Helliwell for introducing the new IUCr forum at
http://forums.iucr.org on diffraction data deposition.

The Diffraction Data Deposition Working Group (DDDWG) has been
established by the IUCr to address the growing calls within the
crystallographic community for the deposition of primary diffraction
images. It is not restricted to macromolecular crystallography, and
indeed is interested in the requirements for deposition of primary
experimental data from all IUCr Commissions. It is likely that
requirements for metadata, data citation and distributed storage
will be common to many fields. Nevertheless, the macromolecular
community is clearly a large and important constituency, and
the Working Group will welcome your input.

The forum can be reached directly at the URL
http://forums.iucr.org/viewforum.php?f=21

It can be read by anyone, so you do not need to register to read the
existing posts. You will, however, need to register if you want to
contribute your own posts. Instructions for doing this are found at
http://forums.iucr.org/viewtopic.php?f=19&t=50
although they should also be readily deducible from the front page for
anyone who has previously used forum software.

So far as possible, we would ask contributors to try to structure their
discussions into distinct topics. You can reply to an existing topic
(using the "REPLY POST" button), to build up a coherent discussion on
that specific point. If you wish to raise a new line of discussion,
use the "NEW TOPIC" button on the forum contents page, and try to
give a concise title to the new topic you are introducing.

The forums have their own area for asking questions and getting help about
how the software works (http://forums.iucr.org/viewforum.php?f=19); but if
in doubt, please feel free to email me directly (b...@iucr.org).

Regards
Brian McMahon
_
Brian McMahon   tel: +44 1244 342878
Research and Development Officerfax: +44 1244 314888
International Union of Crystallographye-mail:  b...@iucr.org
5 Abbey Square, Chester CH1 2HU, England

[ccp4bb] error message in scalepack

[fulvio saccoccia]

Dear ccp4bber,
 I received the following message, during a run with scaling:

forrtl: error (72): floating overflow

does anyone know what does it means and how can I overcome it?

I am trying to scale 900 frames, with data integrated to 3.3 A
resolution.

Thanks in advance

Fulvio Saccoccia, PhD student
Dept. of Biochemical Sciences
Sapienza University of Rome

Re: [ccp4bb] Dennis Ritchie

[Gerard Bricogne]

Dear Miguel,

 Your list of two astounding achievements by Ritchie reminds me of an
old satire of mutual assessment within academia, in cartoon form, showing a
group of cavemen talking intensely and secretively to each other about
another one who is standing anxiously in the distance. One of those in the
group is saying: "OK, so he discovered fire and invented the wheel - but
what has he done since?".


 With best wishes,
 
  Gerard.

--
On Tue, Oct 18, 2011 at 10:58:05AM +0200, Miguel Ortiz Lombardía wrote:
> Hi community,
> 
> I have been waiting for someone more knowledgeable to write about the
> passing away of Dennis Ritchie (8 October) especially after the recent
> obituaries posted in the list. I confess I know little about him, except:
> 
> 1/ He created the C language ( and together with Brian Kernighan wrote
> an extremely useful book about it )
> 2/ He and Ken Thompson were key in the development of something called
> UNIX...
> 
> Undoubtedly, he made an impact in our field.
> 
> 
> -- 
> Miguel
> 
> Architecture et Fonction des Macromolécules Biologiques (UMR6098)
> CNRS, Universités d'Aix-Marseille I & II
> Case 932, 163 Avenue de Luminy, 13288 Marseille cedex 9, France
> Tel: +33(0) 491 82 55 93
> Fax: +33(0) 491 26 67 20
> mailto:miguel.ortiz-lombar...@afmb.univ-mrs.fr
> http://www.afmb.univ-mrs.fr/Miguel-Ortiz-Lombardia

-- 

 ===
 * *
 * 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 *
 * *
 ===

[ccp4bb] Assay of enzyme from thermophile

[Kayashree M]

Dear users, Pardon me for the non-crystallography related question, Can anyone provide some papers regarding the assay ofenzymes from hypertherphilic /thermophilic organisms? ie,assays at high temperatures..Thanking youWith RegardsM. Kavyashree -- 
This message has been scanned for viruses and
dangerous content by
MailScanner, and is
believed to be clean.

Re: [ccp4bb] IUCr committees, depositing images

[Chris Morris]

Some crystals are hard to make, so storing all the data the best way to get 
reproducibility. On the other hand, no one needs more images of lysozyme. So 
using the same standard for every deposition doesn't sound right.

The discussion should be held on the basis of overall cost to the research 
budget - not on the assumption that some costs can be externalised. It is too 
easy to say "you should store the images, in case I want to reprocess them 
sometime". IT isn't free, nor is it always cheaper than the associated 
experimental work. The key comparison is:

   Cost of growing new crystals + cost of beam line time
   
With:
  
   Cost of storing images * probability of processing them again

At present, detectors are improving more quickly than processing software. 
Sample preparation methods are also improving. These forces both press downward 
the probability that a particular image will ever be reprocessed. 

regards,
Chris

Chris Morris  
chris.mor...@stfc.ac.uk   
Tel: +44 (0)1925 603689  Fax: +44 (0)1925 603634
Mobile: 07921-717915
Skype: chrishgmorris
http://pims.structuralbiology.eu/
http://www.citeulike.org/blog/chrishmorris
Daresbury Lab,  Daresbury,  Warrington,  UK,  WA4 4AD

Re: [ccp4bb] error message in scalepack

[fulvio saccoccia]

Solved.
I run scalepack under C shell (csh) and seems it works fine.

Fulvio

Il giorno mar, 18/10/2011 alle 12.18 +0200, fulvio saccoccia ha scritto:
> Dear ccp4bber,
>  I received the following message, during a run with scaling:
> 
> forrtl: error (72): floating overflow
> 
> does anyone know what does it means and how can I overcome it?
> 
> I am trying to scale 900 frames, with data integrated to 3.3 A
> resolution.
> 
> Thanks in advance
> 
> Fulvio Saccoccia, PhD student
> Dept. of Biochemical Sciences
> Sapienza University of Rome

Re: [ccp4bb] Assay of enzyme from thermophile

[Partha Chakrabarti]

You can do it without having to do an assay at high temperature, because the
substrate stability would also change at higher temperature. What you could
do is the following:

1. Use a PCR machine to heat the enzyme, and then cool it down.
2. Keep one fraction at 4C / RT separately.
3. Do the assays and take the ratio (residual activity).
4. Make sure you normalize against protein concentration if you are checking
different mutations.
5. Do it at different pH and duration of heating.

HTH,
Partha


On Tue, Oct 18, 2011 at 3:48 PM, Kayashree M  wrote:

> Dear users,
>
> Pardon me for the non-crystallography related question,
> Can anyone provide some papers regarding the assay of
> enzymes from hypertherphilic /thermophilic organisms? ie,
> assays at high temperatures..
>
> Thanking you
> With Regards
> M. Kavyashree
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* , and is
> believed to be clean.

Re: [ccp4bb] IUCr committees, depositing images

[Peter Keller]

Perhaps this kind of discussion that should be continued on the IUCr
forums, once people have had a chance to register. However, to answer
these particular points:

On Tue, 2011-10-18 at 10:52 +, Chris Morris wrote:
> Some crystals are hard to make, so storing all the data the best way to get 
> reproducibility. On the other hand, no one needs more images of lysozyme. So 
> using the same standard for every deposition doesn't sound right.

Yes, good point, but...

> The discussion should be held on the basis of overall cost to the research 
> budget - not on the assumption that some costs can be externalised. It is too 
> easy to say "you should store the images, in case I want to reprocess them 
> sometime". IT isn't free, nor is it always cheaper than the associated 
> experimental work. The key comparison is:
> 
>Cost of growing new crystals + cost of beam line time
>
> With:
>   
>Cost of storing images * probability of processing them again
> 
> At present, detectors are improving more quickly than processing software. 
> Sample preparation methods are also improving. These forces both press 
> downward the probability that a particular image will ever be reprocessed. 

... this analysis assumes that the only value of the images are for an
improved structure determination of that particular sample in order to
get new scientific insights about it. Software and methods development
have different requirements. The kinds of images that are of interest
may include:

 (1) Hard-to-process images of various kinds

 (2) Images collected using non-obvious data collection protocols,
especially if someone has put a lot of time and thought into designing
them.

>From that point of view, it doesn't matter if a high-quality structure
of the same protein has since been refined and deposited - the original
images can still be useful.

Regards,
Peter.

-- 
Peter Keller Tel.: +44 (0)1223 353033
Global Phasing Ltd., Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom

Re: [ccp4bb] IUCr committees, depositing images

[Felix Frolow]

I could not agree less. There is constant development of the software for 
refinement that allow to do things that were not
possible or were not necessary  in the past such as intelligent refinement of 
occupancies of mutually exclusive sites, entities and conformations.
I frequently remeasure lysozyme crystals. I use them as a test system for the 
beam lines, new detectors, novel software developments, refinement improvement 
etc. Sometimes I am collecting data in quite different wavelength than of 
existing structures. And what about diffraction  data from a chemically 
modified lysozyme molecule?
They are good data that show evolution of the beam line stations if they are 
keeper in historical order.
To store them all, or not to store at all…
Storage of the diffraction data is not a drinking club with muscle-bound 
selectors outside :-)
Felix Frolow
Dr Felix Frolow   
Professor of Structural Biology and Biotechnology
Department of Molecular Microbiology
and Biotechnology
Tel Aviv University 69978, Israel

Acta Crystallographica F, co-editor

e-mail: mbfro...@post.tau.ac.il
Tel:  ++972-3640-8723
Fax: ++972-3640-9407
Cellular: 0547 459 608

On Oct 18, 2011, at 12:52 , Chris Morris wrote:

> Some crystals are hard to make, so storing all the data the best way to get 
> reproducibility. On the other hand, no one needs more images of lysozyme. So 
> using the same standard for every deposition doesn't sound right.
> 
> The discussion should be held on the basis of overall cost to the research 
> budget - not on the assumption that some costs can be externalised. It is too 
> easy to say "you should store the images, in case I want to reprocess them 
> sometime". IT isn't free, nor is it always cheaper than the associated 
> experimental work. The key comparison is:
> 
>   Cost of growing new crystals + cost of beam line time
> 
> With:
> 
>   Cost of storing images * probability of processing them again
> 
> At present, detectors are improving more quickly than processing software. 
> Sample preparation methods are also improving. These forces both press 
> downward the probability that a particular image will ever be reprocessed. 
> 
> regards,
> Chris
> 
> Chris Morris  
> chris.mor...@stfc.ac.uk   
> Tel: +44 (0)1925 603689  Fax: +44 (0)1925 603634
> Mobile: 07921-717915
> Skype: chrishgmorris
> http://pims.structuralbiology.eu/
> http://www.citeulike.org/blog/chrishmorris
> Daresbury Lab,  Daresbury,  Warrington,  UK,  WA4 4AD

[ccp4bb] How can improve diffraction quality

[Afshan Begum]

 Dear ccp4 user

I am facing one crucial problem regarding diffraction. Actually the size of my 
crystal is good enough 0.5mm but it  was diffracted only 4 A.

The conditions of crystallization recipes are 4.5% PEG 1000, 0.1M Tris and 25mM 
Na citrate. I really need your suggestions regarding  how can  i improve my 
diffraction quality?

Your support is highly appreciable.



Best Regards

AFSHAN

Re: [ccp4bb] How can improve diffraction quality

[elizabeth . duke]

Hi

You don't give any details of how you are collecting your data or what the 
protein is (small, medium, large, solvent content, unit cell etc etc). But at 
first glance your crystal is huge by "modern day standards". Very often 
large crystals are of poorer overall quality than smaller ones.

If you are trying to "freeze" a crystal of that size you are likely to run into 
problems with data quality.

I would suggest trying a smaller crystal.. but without more information it 
is difficult to provide any real advice.

Good luck!

Liz

Dr. Liz Duke
Principal Beamline Scientist
Diamond Light Source
Harwell Science and Innovation Campus
Chilton
OX11 0DE
UK

Tel. 01235 778057
Mob. 07920 138148

From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Afshan 
Begum
Sent: 18 October 2011 12:45
To: ccp4bb
Subject: [ccp4bb] How can improve diffraction quality


 Dear ccp4 user

I am facing one crucial problem regarding diffraction. Actually the size of my 
crystal is good enough 0.5mm but it  was diffracted only 4 A.

The conditions of crystallization recipes are 4.5% PEG 1000, 0.1M Tris and 25mM 
Na citrate. I really need your suggestions regarding  how can  i improve my 
diffraction quality?

Your support is highly appreciable.

Best Regards

AFSHAN

Re: [ccp4bb] How can improve diffraction quality

[Charles Allerston]

Silver bullet
Additive screens
Methylation
Construct boundaries
in situ proteolysis
Have you got a ligand?  Stick in in there!
Do you have an expression tag?  Cleave it/leave it on.
What is in your protein buffer?  Mess about with that?
Temperature gradients
How is your purity?
How quickly are you getting this in to trays?  Can you speed this up?  Might be 
a factor.
Annealing at the beamline?

etc.

cheers,

charlie



From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] On Behalf Of Afshan Begum 
[afshan...@yahoo.com]
Sent: 18 October 2011 12:45
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] How can  improve  diffraction quality

 Dear ccp4 user

I am facing one crucial problem regarding diffraction. Actually the size of my 
crystal is good enough 0.5mm but it  was diffracted only 4 A.

The conditions of crystallization recipes are 4.5% PEG 1000, 0.1M Tris and 25mM 
Na citrate. I really need your suggestions regarding  how can  i improve my 
diffraction quality?

Your support is highly appreciable.

Best Regards

AFSHAN

Re: [ccp4bb] IUCr committees, depositing images

[Boaz Shaanan]

Hi Felix,

Excuse my question, but what have you discovered about lysozyme that we haven't 
already known before which justifies all these efforts?
After all, we're mostly after finding solutions to biological problems, aren't 
we?

  Boaz


Boaz Shaanan, Ph.D.
Dept. of Life Sciences
Ben-Gurion University of the Negev
Beer-Sheva 84105
Israel

E-mail: bshaa...@bgu.ac.il
Phone: 972-8-647-2220  Skype: boaz.shaanan
Fax:   972-8-647-2992 or 972-8-646-1710






From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Felix Frolow 
[mbfro...@post.tau.ac.il]
Sent: Tuesday, October 18, 2011 1:40 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] IUCr committees, depositing images

I could not agree less. There is constant development of the software for 
refinement that allow to do things that were not
possible or were not necessary  in the past such as intelligent refinement of 
occupancies of mutually exclusive sites, entities and conformations.
I frequently remeasure lysozyme crystals. I use them as a test system for the 
beam lines, new detectors, novel software developments, refinement improvement 
etc. Sometimes I am collecting data in quite different wavelength than of 
existing structures. And what about diffraction  data from a chemically 
modified lysozyme molecule?
They are good data that show evolution of the beam line stations if they are 
keeper in historical order.
To store them all, or not to store at all…
Storage of the diffraction data is not a drinking club with muscle-bound 
selectors outside :-)
Felix Frolow
Dr Felix Frolow
Professor of Structural Biology and Biotechnology
Department of Molecular Microbiology
and Biotechnology
Tel Aviv University 69978, Israel

Acta Crystallographica F, co-editor

e-mail: mbfro...@post.tau.ac.il
Tel:  ++972-3640-8723
Fax: ++972-3640-9407
Cellular: 0547 459 608

On Oct 18, 2011, at 12:52 , Chris Morris wrote:

> Some crystals are hard to make, so storing all the data the best way to get 
> reproducibility. On the other hand, no one needs more images of lysozyme. So 
> using the same standard for every deposition doesn't sound right.
>
> The discussion should be held on the basis of overall cost to the research 
> budget - not on the assumption that some costs can be externalised. It is too 
> easy to say "you should store the images, in case I want to reprocess them 
> sometime". IT isn't free, nor is it always cheaper than the associated 
> experimental work. The key comparison is:
>
>   Cost of growing new crystals + cost of beam line time
>
> With:
>
>   Cost of storing images * probability of processing them again
>
> At present, detectors are improving more quickly than processing software. 
> Sample preparation methods are also improving. These forces both press 
> downward the probability that a particular image will ever be reprocessed.
>
> regards,
> Chris
> 
> Chris Morris
> chris.mor...@stfc.ac.uk
> Tel: +44 (0)1925 603689  Fax: +44 (0)1925 603634
> Mobile: 07921-717915
> Skype: chrishgmorris
> http://pims.structuralbiology.eu/
> http://www.citeulike.org/blog/chrishmorris
> Daresbury Lab,  Daresbury,  Warrington,  UK,  WA4 4AD

Re: [ccp4bb] How can improve diffraction quality

[vandana kukshal]

Hello
You can do dehydration of crystal  to get better diffraction
...go through this reference

Dehydration Converts DsbG Crystal Diffraction from Low to High Resolution

Begoña 
Heras
1 
, Melissa A. 
Edeling
1 
, Karl A. 
Byriel
1 
, Alun 
Jones
1 
, Satish 
Raina
2 
, Jennifer L. 
Martin
1 
,
Structure, Vol. 11, 139–145, February, 2003,




On Tue, Oct 18, 2011 at 5:52 PM, Charles Allerston <
charles.allers...@sgc.ox.ac.uk> wrote:

> Silver bullet
> Additive screens
> Methylation
> Construct boundaries
> in situ proteolysis
> Have you got a ligand?  Stick in in there!
> Do you have an expression tag?  Cleave it/leave it on.
> What is in your protein buffer?  Mess about with that?
> Temperature gradients
> How is your purity?
> How quickly are you getting this in to trays?  Can you speed this up?
>  Might be a factor.
> Annealing at the beamline?
>
> etc.
>
> cheers,
>
> charlie
>
>
> 
> From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] On Behalf Of Afshan
> Begum [afshan...@yahoo.com]
> Sent: 18 October 2011 12:45
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] How can  improve  diffraction quality
>
>  Dear ccp4 user
>
> I am facing one crucial problem regarding diffraction. Actually the size of
> my crystal is good enough 0.5mm but it  was diffracted only 4 A.
>
> The conditions of crystallization recipes are 4.5% PEG 1000, 0.1M Tris and
> 25mM Na citrate. I really need your suggestions regarding  how can  i
> improve my diffraction quality?
>
> Your support is highly appreciable.
>
> Best Regards
>
> AFSHAN
>



-- 
Vandana kukshal

Re: [ccp4bb] IUCr committees, depositing images

[Enrico Stura]

With improving techniques, we should always be making progress!
If we are trying to answer a biological question that is really important,  
we would be better off
improving the purification, the crystallization, the cryo-conditions  
instead of having to rely on

processing old images with new software.

I have 10 years  worth of images. I have reprocessed very few of them and  
never made any
sensational progress using the new software. Poor diffraction is poor  
diffraction.

Money can be better spent buying a wine cellar, storage works for wine.

Enrico.

On Tue, 18 Oct 2011 14:51:27 +0200, Boaz Shaanan  
 wrote:



Hi Felix,

Excuse my question, but what have you discovered about lysozyme that we  
haven't already known before which justifies all these efforts?
After all, we're mostly after finding solutions to biological problems,  
aren't we?


  Boaz


Boaz Shaanan, Ph.D.
Dept. of Life Sciences
Ben-Gurion University of the Negev
Beer-Sheva 84105
Israel

E-mail: bshaa...@bgu.ac.il
Phone: 972-8-647-2220  Skype: boaz.shaanan
Fax:   972-8-647-2992 or 972-8-646-1710






From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Felix  
Frolow [mbfro...@post.tau.ac.il]

Sent: Tuesday, October 18, 2011 1:40 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] IUCr committees, depositing images

I could not agree less. There is constant development of the software  
for refinement that allow to do things that were not
possible or were not necessary  in the past such as intelligent  
refinement of occupancies of mutually exclusive sites, entities and  
conformations.
I frequently remeasure lysozyme crystals. I use them as a test system  
for the beam lines, new detectors, novel software developments,  
refinement improvement etc. Sometimes I am collecting data in quite  
different wavelength than of existing structures. And what about  
diffraction  data from a chemically modified lysozyme molecule?
They are good data that show evolution of the beam line stations if they  
are keeper in historical order.

To store them all, or not to store at all…
Storage of the diffraction data is not a drinking club with muscle-bound  
selectors outside :-)

Felix Frolow
Dr Felix Frolow
Professor of Structural Biology and Biotechnology
Department of Molecular Microbiology
and Biotechnology
Tel Aviv University 69978, Israel

Acta Crystallographica F, co-editor

e-mail: mbfro...@post.tau.ac.il
Tel:  ++972-3640-8723
Fax: ++972-3640-9407
Cellular: 0547 459 608

On Oct 18, 2011, at 12:52 , Chris Morris wrote:

Some crystals are hard to make, so storing all the data the best way to  
get reproducibility. On the other hand, no one needs more images of  
lysozyme. So using the same standard for every deposition doesn't sound  
right.


The discussion should be held on the basis of overall cost to the  
research budget - not on the assumption that some costs can be  
externalised. It is too easy to say "you should store the images, in  
case I want to reprocess them sometime". IT isn't free, nor is it  
always cheaper than the associated experimental work. The key  
comparison is:


  Cost of growing new crystals + cost of beam line time

With:

  Cost of storing images * probability of processing them again

At present, detectors are improving more quickly than processing  
software. Sample preparation methods are also improving. These forces  
both press downward the probability that a particular image will ever  
be reprocessed.


regards,
Chris

Chris Morris
chris.mor...@stfc.ac.uk
Tel: +44 (0)1925 603689  Fax: +44 (0)1925 603634
Mobile: 07921-717915
Skype: chrishgmorris
http://pims.structuralbiology.eu/
http://www.citeulike.org/blog/chrishmorris
Daresbury Lab,  Daresbury,  Warrington,  UK,  WA4 4AD



--
Enrico A. Stura D.Phil. (Oxon) ,Tel: 33 (0)1 69 08 4302 Office
Room 19, Bat.152,   Tel: 33 (0)1 69 08 9449Lab
LTMB, SIMOPRO, IBiTec-S, CE Saclay, 91191 Gif-sur-Yvette,   FRANCE
http://www-dsv.cea.fr/en/institutes/institute-of-biology-and-technology-saclay-ibitec-s/unites-de-recherche/department-of-molecular-engineering-of-proteins-simopro/molecular-toxinology-and-biotechnology-laboratory-ltmb/crystallogenesis-e.-stura
http://www.chem.gla.ac.uk/protein/mirror/stura/index2.html
e-mail: est...@cea.fr Fax: 33 (0)1 69 08 90 71

[ccp4bb] CCP4 Study Weekend 2012 - Data Collection and Processing

[ronan . keegan]

Dear All,

This is a reminder about this coming January's CCP4 Study Weekend taking place 
from the 4th - 6th of January at Warwick University in the UK. The topic for 
the 2012 meeting will be "Data Collection and Processing" and a provisional 
programme is now available. The meeting will cover all aspects of data 
collection and processing with presentations from eminent researchers in the 
field from all around the world. To view the programme and for registration 
details please visit the CCP4 Study Weekend 2012 website:

http://www.cse.scitech.ac.uk/events/CCP4_2012/

As always, we have bursaries available to students to help with costs. However, 
numbers are limited so please get your registration in early if you wish to 
take advantage of our support. 

We look forward to seeing you in Warwick.

Kind regards,

Katherine, Johan and all of us here in CCP4

Re: [ccp4bb] IUCr committees, depositing images

[Richard Gillilan]

For the record, the amount of disk storage space per unit cost has doubled 
every 14 months for the last 30 years.  It's an exponential relationship:
www.mkomo.com/cost-per-gigabyte

So data generated at a very high rate today, will be trivial to store in the 
near future.  That's not to say it is cost free, of course ... but 
exponentially approaching free. 

I worked at a Supercomputing facility for 7 years. At that time whole rooms 
were filled with state-of-the-art tape archive robots that could hold an 
unimaginable amount of data: a whole terabyte. Today, of course, that same 
volume costs under 100 USD with much faster I/O ... and I have personal copies 
of everything I generated (even digitized, uncompressed analog video).

To keep data backed up and online, of course costs something, but 
distributed/cloud computing is also changing that picture dramatically.

I am curious to know: those who have Pilatus 6M, for example. How much data do 
you generate in  a year? 

I suspect this is limited by beam intensity ... at the moment. 

Richard


On Oct 18, 2011, at 6:52 AM, Chris Morris wrote:

> Some crystals are hard to make, so storing all the data the best way to get 
> reproducibility. On the other hand, no one needs more images of lysozyme. So 
> using the same standard for every deposition doesn't sound right.
> 
> The discussion should be held on the basis of overall cost to the research 
> budget - not on the assumption that some costs can be externalised. It is too 
> easy to say "you should store the images, in case I want to reprocess them 
> sometime". IT isn't free, nor is it always cheaper than the associated 
> experimental work. The key comparison is:
> 
>   Cost of growing new crystals + cost of beam line time
> 
> With:
> 
>   Cost of storing images * probability of processing them again
> 
> At present, detectors are improving more quickly than processing software. 
> Sample preparation methods are also improving. These forces both press 
> downward the probability that a particular image will ever be reprocessed. 
> 
> regards,
> Chris

Re: [ccp4bb] Dennis Ritchie

[Sabuj Pattanayek]

The silence on this list was deafening.

> group is saying: "OK, so he discovered fire and invented the wheel - but
> what has he done since?".

1983 Turing Award
1990 IEEE Hamming medal
1999 National Medal of Technology
2011 Japan Prize for Information and Communications (while he was
still alive I think)

Even if he hadn't done anything technologically innovative that was
made public since C and UNIX, his C book (which was the first
programming book I read in it's entirety) and the foundations of his
OS have helped countless millions of people. I find it sad that in
many undergrad computer science curricula, C is no longer being
taught. If you want to understand how software works under the hood
you either learn assembly or C.

Re: [ccp4bb] Dennis Ritchie

[Gerard Bricogne]

Dear Sabuj,

 Your opening remark made me worried that the facetious "what has he
done since?" might be taken seriously ... . That was not what was intended!
A variant of the joke was about a similar committee in charge of evaluating
God's performance, and coming up with "Sure, he created the Universe, but
what has he done since?". I was certainly not implying that Dennis Ritchie
had slept on his laurels after the two pieces of work Miguel mentioned - I
was only trying to share some light humour about the often over-competitive
and pettily critical system under which we all have to live and operate.


 With best wishes,
 
  Gerard.

--
On Tue, Oct 18, 2011 at 09:36:21AM -0500, Sabuj Pattanayek wrote:
> The silence on this list was deafening.
> 
> > group is saying: "OK, so he discovered fire and invented the wheel - but
> > what has he done since?".
> 
> 1983 Turing Award
> 1990 IEEE Hamming medal
> 1999 National Medal of Technology
> 2011 Japan Prize for Information and Communications (while he was
> still alive I think)
> 
> Even if he hadn't done anything technologically innovative that was
> made public since C and UNIX, his C book (which was the first
> programming book I read in it's entirety) and the foundations of his
> OS have helped countless millions of people. I find it sad that in
> many undergrad computer science curricula, C is no longer being
> taught. If you want to understand how software works under the hood
> you either learn assembly or C.

Re: [ccp4bb] IUCr committees, depositing images

[Peter Keller]

Dear Enrico,

Please don't get me wrong: what you are saying is not incorrect, but it
is only half the story.

On Tue, 2011-10-18 at 15:13 +0200, Enrico Stura wrote:
> With improving techniques, we should always be making progress!

Yes, of course!

> If we are trying to answer a biological question that is really important,  
> we would be better off
> improving the purification, the crystallization, the cryo-conditions  

You have left X-ray crystallography out of this list. It is a technique
like the others, and can also be improved :-)

It may be true that the number of crystallographers that are working on
improving instrumental methodology and software is small compared to the
number working on improving wet-lab techniques, but that number is not
zero, and the contribution is significant. The rest of you benefit from
that work!

> instead of having to rely on
> processing old images with new software.
> 
> I have 10 years  worth of images. I have reprocessed very few of them and  
> never made any
> sensational progress using the new software. Poor diffraction is poor  
> diffraction.

Maybe so, but certain types of datasets are useful for methods and
software development, even if no new biological insights could be gained
by reprocessing them. These datasets are often hard to get hold of in
practice, especially when they are in someone's lab on a tape that
no-one has a reader for any more.

Obtaining protein, growing crystals and collecting new data in such a
way that the interesting features of those datasets are reproduced can
be much much harder than curating the images would be. This is
especially true for software-oriented people like us who don't have
regular access to wet-lab facilities.

> Money can be better spent buying a wine cellar, storage works for wine.

Images have already been lost that ought to have been kept. The
questions are: how to select the datasets that are potentially of value,
and how to make sure that they don't disappear.

Regards,
Peter.

-- 
Peter Keller Tel.: +44 (0)1223 353033
Global Phasing Ltd., Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom

[ccp4bb] Phenix building residues not found in input sequence file

[Allan Pang]

Hi everyone,

Apparently my Phenix (1.6.3-473) is building in extra residues in the  
C-terminal region, which is not found in my input sequence file.


It's trying to build a model which is longer than I expected. Phenix  
building 87 extra amino acids. Any clue what's wrong?


I made sure that these amino acids are not residues found in the  
N-terminal region or anywhere else in the protein.


Allan

--
Allan Pang

PhD Student

G35 Joseph Priestley Building
Queen Mary University of London
London
E1 4NS

Phone number: 02078828480

Re: [ccp4bb] IUCr committees, depositing images

[苏晓东]

Sorry if this message reads a bit out of date, it has been sent two days ago 
without success, I am trying to sent it one more time. 

XDS

发件人: gsw...@pku.edu.cn
收件人: Felix Frolow , CCP4BB@JISCMAIL.AC.UK, 
x...@pku.edu.cn
已发送邮件: Tue, 18 Oct 2011 10:36:51 +0800 (CST)
主题: Re: [ccp4bb] IUCr committees, depositing images


Dear All, 

Since John has responded to the issues raised by Tom and several responders, 
and he has just described the overall goal of IUCr DDD WG (Diffraction Data 
Deposition Working Group), I will just second on this important issue 
particularly for the future biological macromolecular crystallography. 

In my opinion, the reasons for raw data deposition can be summarized as 
following (overlapping with others)
* Keep permanent experimental records; this may not be done well for all 
crystallographers. 
* Make it possible for rigorous thorough check by reviewers as FF suggested in 
this mail; in fact this has been a problem for some structures published 
prestigious journals, particularly for low-resolution results, and these 
low-resolution structures tend to become more and more. 
* Minimize falsification and other types of mistakes and misconducts in 
structural biology.
* Make it easier for validations/collaborations, I bet many structures in PDB 
are wrong, but there is no way to find out by the current data deposition. 
* Good for methods developers; 
 
I also agree that there are essentially no much technical problem for the raw 
image(data) depostion, this is especially true if we leave the deposition at or 
near the synchrotron sites.  I hope we will join in John's forum on this 
important issue at: 
http://forums.iucr.org/


XDS


Xiao-Dong Su, Professor
 Chairman of the Commission on Biological Macromolecules (CBM),
 International Union of Crystallography (IUCr);
 
 School of Life Sciences, Peking University
 100871 Beijing, China
 Phone:  +86-10-62759743
 FAX: +86-10-62765669
 E-mail: x...@pku.edu.cn

- 原始邮件 -
发件人: Felix Frolow 
收件人: CCP4BB@JISCMAIL.AC.UK
已发送邮件: Mon, 17 Oct 2011 03:31:52 +0800 (CST)
主题: Re: [ccp4bb] IUCr committees, depositing images

On the deposition of raw data:
Committees, wherever you are!
I guess that abstaining from storing the raw diffraction data in the form of  
frames is not very wise
whatever its size is. I regret that for some PDB entries I do not have 
diffraction data (needless to say that authors
do not submitted even  structure factors). 
I maintain a bit more than 1.2 T diffraction data starting from 2001 and all is 
nicely
resides on two small WD pocket disks (needless to say that I have several 
copies of the data).
Generally I have all data I ever collected going back to beginning of 80's, but 
I am to lazy to reform DAT tapes.
Sure, running Pilatus for an olympic record, we will go home with several T of 
data after 24 h (will we?).
But this is an abuse of the system. The final goal is the structure 
determination, and there are much less 
good crystals everywhere in one year that  one Pilatus could collect in one 
week.
But to decide fast if the crystal diffraction data from Pilatus is good for 
storage or even for measurement whatever the speed of data collection is, good 
data processing
software is needed. I personnaly think that there is only one, the one.
Anyhow, I think if the author wish to publish his structure, and it is 
important, and I am a reviewer, and it is going
to prestigious journal,  I will reprocess his data and will check his way to 
the final crystal structure solution from the beginning.
It is as in mathematics. If someone claim that he solved a long-staing problem 
from the past, he will not go away from his envious colleagues, who 
will drop everything and will sit and check, until they will find a mistake. 
What a pleasure!!!
And if there are no mistakes - chapeau !!!

FF
 
Dr Felix Frolow   
Professor of Structural Biology and Biotechnology
Department of Molecular Microbiology
and Biotechnology
Tel Aviv University 69978, Israel

Acta Crystallographica F, co-editor

e-mail: mbfro...@post.tau.ac.il
Tel:  ++972-3640-8723
Fax: ++972-3640-9407
Cellular: 0547 459 608

On Oct 16, 2011, at 20:38 , Frank von Delft wrote:

> On the deposition of raw data:
> 
> I recommend to the committee that before it convenes again, every member 
> should go collect some data on a beamline with a Pilatus detector [feel free 
> to join us at Diamond].  Because by the probable time any recommendations 
> actually emerge, most beamlines will have one of those (or similar), we'll be 
> generating more data than the LHC, and users will be happy just to have it 
> integrated, never mind worry about its fate.
> 
> That's not an endorsement, btw, just an observation/prediction.
> 
> phx.
> 
> 
> 
> 
> On 14/10/2011 23:56, Thomas C. Terwilliger wrote:
>> For those who have strong opinions on what data should be deposited...
>> 
>> The IUCR is just starting a serious discussion of this subject. Two
>> committees, the "Data Deposi

Re: [ccp4bb] Dennis Ritchie

[DUMAS Philippe (UDS)]

Le Mardi 18 Octobre 2011 16:36 CEST, Sabuj Pattanayek  a 
écrit:

Should I understand that Gérard Brigogne really meant that Ritchie's 
achievements were peanuts ?
Yet, after so many years in England I thought Gerard mastered  British humour 
rather well...
Encore un effort Gérard
Philippe Dumas

> The silence on this list was deafening.
>
> > group is saying: "OK, so he discovered fire and invented the wheel - but
> > what has he done since?".
>
> 1983 Turing Award
> 1990 IEEE Hamming medal
> 1999 National Medal of Technology
> 2011 Japan Prize for Information and Communications (while he was
> still alive I think)
>
> Even if he hadn't done anything technologically innovative that was
> made public since C and UNIX, his C book (which was the first
> programming book I read in it's entirety) and the foundations of his

> OS have helped countless millions of people. I find it sad that in
> many undergrad computer science curricula, C is no longer being
> taught. If you want to understand how software works under the hood
> you either learn assembly or C.

[ccp4bb] Fixing cis peptides

[Jason Porta]

Hi everybody,

I am currently refining a 2.2 A crystal structure with a very mobile subdomain. 
The initial density for this subdomain was very weak, however, I was able to 
rebuild it using low resolution omit maps (and some perturbing of atomic 
coordinates). When I refine the structure, four of the peptide bonds go into 
the cis position. When I fix it manually, many clashes are introduced, and even 
then, the structure just refines back into the cis positions. 

Does anyone have a good technique for dealing with cis bonds? Or any advice on 
how I could fix this?

regards,
Jason P

Re: [ccp4bb] IUCr committees, depositing images

[Enrico Stura]

Dear Peter,

How many crystallographers does it take to transform bad data into good  
data?
None, you need a modeller. Only a modeller can give you a structure with  
perfect
geometry. Data just introduces experimental errors into what would  
otherwise be a perfect

structure.

If you have good data do you need crystallographers?
...

Of course there all the cases in between. That ... you are right, is the  
other half of the story.


From a biological point of view, only borderline cases make "cents" ($+€)  
to store.
The experimenter in consultation with a beamline scientist at an SR  
facility is the best
small commitee suitable to evaluate what is worth keeping. I am sure that  
the images
that are worth storing for a long long time would fit on a few Tb at a  
reasonable cost.
Storing everything would make it harder to find something worth improving  
in the future.


Enrico.


On Tue, 18 Oct 2011 17:12:42 +0200, Peter Keller  
 wrote:



Dear Enrico,

Please don't get me wrong: what you are saying is not incorrect, but it
is only half the story.

On Tue, 2011-10-18 at 15:13 +0200, Enrico Stura wrote:

With improving techniques, we should always be making progress!


Yes, of course!

If we are trying to answer a biological question that is really  
important,

we would be better off
improving the purification, the crystallization, the cryo-conditions


You have left X-ray crystallography out of this list. It is a technique
like the others, and can also be improved :-)

It may be true that the number of crystallographers that are working on
improving instrumental methodology and software is small compared to the
number working on improving wet-lab techniques, but that number is not
zero, and the contribution is significant. The rest of you benefit from
that work!


instead of having to rely on
processing old images with new software.

I have 10 years  worth of images. I have reprocessed very few of them  
and

never made any
sensational progress using the new software. Poor diffraction is poor
diffraction.


Maybe so, but certain types of datasets are useful for methods and
software development, even if no new biological insights could be gained
by reprocessing them. These datasets are often hard to get hold of in
practice, especially when they are in someone's lab on a tape that
no-one has a reader for any more.

Obtaining protein, growing crystals and collecting new data in such a
way that the interesting features of those datasets are reproduced can
be much much harder than curating the images would be. This is
especially true for software-oriented people like us who don't have
regular access to wet-lab facilities.


Money can be better spent buying a wine cellar, storage works for wine.


Images have already been lost that ought to have been kept. The
questions are: how to select the datasets that are potentially of value,
and how to make sure that they don't disappear.

Regards,
Peter.




--
Enrico A. Stura D.Phil. (Oxon) ,Tel: 33 (0)1 69 08 4302 Office
Room 19, Bat.152,   Tel: 33 (0)1 69 08 9449Lab
LTMB, SIMOPRO, IBiTec-S, CE Saclay, 91191 Gif-sur-Yvette,   FRANCE
http://www-dsv.cea.fr/en/institutes/institute-of-biology-and-technology-saclay-ibitec-s/unites-de-recherche/department-of-molecular-engineering-of-proteins-simopro/molecular-toxinology-and-biotechnology-laboratory-ltmb/crystallogenesis-e.-stura
http://www.chem.gla.ac.uk/protein/mirror/stura/index2.html
e-mail: est...@cea.fr Fax: 33 (0)1 69 08 90 71

Re: [ccp4bb] Dennis Ritchie

[Sabuj Pattanayek]

> Are you saying that undergraduates do not learn to program any more, or that
> they use a more "advanced" language than C where they don't really learn
> what is going on?

The latter. It's usually Java and .NET nowadays IIRC.

Re: [ccp4bb] Phenix building residues not found in input sequence file

[Vellieux Frederic]

Could you have an unexpected "small subunit" (or some other situation) 
giving additional density that Phenix is building into ? In other words, 
how sure are you of what is present in the crystal ? This is because I 
remember the enzyme methanol dehydrogenase where there was a small 
subunit which had not been evidenced for years...


Fred.

Allan Pang wrote:

Hi everyone,

Apparently my Phenix (1.6.3-473) is building in extra residues in the 
C-terminal region, which is not found in my input sequence file.


It's trying to build a model which is longer than I expected. Phenix 
building 87 extra amino acids. Any clue what's wrong?


I made sure that these amino acids are not residues found in the 
N-terminal region or anywhere else in the protein.


Allan

Re: [ccp4bb] Dennis Ritchie

[Ed Pozharski]

On Tue, 2011-10-18 at 10:58 +0200, Miguel Ortiz Lombardía wrote:
> Hi community,
> 
> I have been waiting for someone more knowledgeable to write about the
> passing away of Dennis Ritchie (8 October) especially after the recent
> obituaries posted in the list. I confess I know little about him, except:
> 
> 1/ He created the C language ( and together with Brian Kernighan wrote
> an extremely useful book about it )
> 2/ He and Ken Thompson were key in the development of something called
> UNIX...
> 
> Undoubtedly, he made an impact in our field.
> 
> 

In my humble opinion, the most important contribution was the
implementation of the portability concept by rewriting the UNIX OS in C.
The main impact of this step (which seems so trivial to us today) was
the creation of the programming community that speaks one language. The
opposite of what legend has god doing to the tower builders of Babel.

The russian translation of Kernighan&Ritchie was my first programming
book, and seemingly the only one I ever needed.



-- 
Ed Pozharski 
University of Maryland - Baltimore

Re: [ccp4bb] Fixing cis peptides

[Boaz Shaanan]

What's wrong with cis-peptides? there are plenty of those in the PDB, 
independent of the presence of  proline. If they fit the density better and 
neighbouring residues are happy, just go with it. The refinement suggests that 
this could indeed be the case.

Boaz 


Boaz Shaanan, Ph.D.
Dept. of Life Sciences
Ben-Gurion University of the Negev
Beer-Sheva 84105
Israel

E-mail: bshaa...@bgu.ac.il
Phone: 972-8-647-2220  Skype: boaz.shaanan
Fax:   972-8-647-2992 or 972-8-646-1710






From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Jason Porta 
[jpo...@unmc.edu]
Sent: Tuesday, October 18, 2011 6:16 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] Fixing cis peptides

Hi everybody,

I am currently refining a 2.2 A crystal structure with a very mobile subdomain. 
The initial density for this subdomain was very weak, however, I was able to 
rebuild it using low resolution omit maps (and some perturbing of atomic 
coordinates). When I refine the structure, four of the peptide bonds go into 
the cis position. When I fix it manually, many clashes are introduced, and even 
then, the structure just refines back into the cis positions.

Does anyone have a good technique for dealing with cis bonds? Or any advice on 
how I could fix this?

regards,
Jason P

Re: [ccp4bb] IUCr committees, depositing images

[Mark J van Raaij]

given that:
- storage is becoming cheaper exponentially,
- computer power is increasing exponentially,
I think there is no reason to not store all images used for solving a structure 
- linked to the pdb entry and properly annotated with beam centre, lambda, 
pixel order and all other necessary processing parameters.

Possible uses:
- programmers of data processing (and experimental phasing) software can test 
their programs routinely on many sets of images instead of just a few, to 
better judge the result of changes they have made to the code.
- the PDB (or someone else), can periodically reprocess all the data with the 
then state-of-the-art software, remodel where necessary and re-refine all the 
structures, and thus periodically improve all the structures in the pdb. This 
does not mean the original authors did a bad job, just that technical 
improvements inevitably will allow doing a better one in the future.

Sure, this does not lead directly to new biomedical insights, but indirectly it 
will.
The improved data processing (and experimental phasing) programs will allow 
solving at least a few, new, structures that otherwise would not be solvable.
The improved old structures in the pdb may allow a few, new, structures to be 
solved by MR that otherwise could not have been solved.
The dataset of better structures will lead to better performance of structure 
prediction programs (better energy calculations etc), allowing better 
modelling. (I was, like Enrico, very sceptical of modelling, until the first 
modelled structure was successfully used in MR to solve a new structure. I now 
believe modelling will play an increasing role).

I agree with Enrico that storing and annotating "failed" data collections will 
be difficult to enforce - I for one would rather concentrate on the data 
collections that did work in that trip (if any), or spend my time drowning 
sorrows, resting and then trying to get better crystals for the next trip, 
rather than filling in meta-data for a data storage facility, even if it is 
only a two-minute job.

Another thing are the in-between cases, datasets collected, processed and for 
which structure solution has been tried but abandoned due to the ratio of 
difficulty / interest being to high (difficulties being irreproducibility of 
crystals, some pathology in the data, etc...). These data I would gladly submit 
for someone else to have a go. Currently, probably no-one would, but in the 
future, due to better software, understanding and possible a new structure in 
the pdb that could be used in MR, the difficulty may go down, and some-one 
might do it if the potential structure is still of interest. This some-one 
could be myself, and the images being stored safely and centrally would make it 
easier also for me to recover them.

Mark J van Raaij
Laboratorio M-4
Dpto de Estructura de Macromoleculas
Centro Nacional de Biotecnologia - CSIC
c/Darwin 3
E-28049 Madrid, Spain
tel. (+34) 91 585 4616
http://www.cnb.csic.es/content/research/macromolecular/mvraaij





On 18 Oct 2011, at 18:19, Enrico Stura wrote:

> Dear Peter,
> 
> How many crystallographers does it take to transform bad data into good data?
> None, you need a modeller. Only a modeller can give you a structure with 
> perfect
> geometry. Data just introduces experimental errors into what would otherwise 
> be a perfect
> structure.
> 
> If you have good data do you need crystallographers?
> ...
> 
> Of course there all the cases in between. That ... you are right, is the 
> other half of the story.
> 
> From a biological point of view, only borderline cases make "cents" ($+€) to 
> store.
> The experimenter in consultation with a beamline scientist at an SR facility 
> is the best
> small commitee suitable to evaluate what is worth keeping. I am sure that the 
> images
> that are worth storing for a long long time would fit on a few Tb at a 
> reasonable cost.
> Storing everything would make it harder to find something worth improving in 
> the future.
> 
> Enrico.
> 
> 
> On Tue, 18 Oct 2011 17:12:42 +0200, Peter Keller  
> wrote:
> 
>> Dear Enrico,
>> 
>> Please don't get me wrong: what you are saying is not incorrect, but it
>> is only half the story.
>> 
>> On Tue, 2011-10-18 at 15:13 +0200, Enrico Stura wrote:
>>> With improving techniques, we should always be making progress!
>> 
>> Yes, of course!
>> 
>>> If we are trying to answer a biological question that is really important,
>>> we would be better off
>>> improving the purification, the crystallization, the cryo-conditions
>> 
>> You have left X-ray crystallography out of this list. It is a technique
>> like the others, and can also be improved :-)
>> 
>> It may be true that the number of crystallographers that are working on
>> improving instrumental methodology and software is small compared to the
>> number working on improving wet-lab techniques, but that number is not
>> zero, and the contribution is significant. The rest of you benefit from
>> that w

Re: [ccp4bb] IUCr committees, depositing images

[Gerard Bricogne]

Dear Enrico, Frank and colleagues,

 I am glad to have suggested that everyone's views on this issue should
be aired out on this BB rather than sent off-list to an IUCr committee
member: this is much more interactive and thought-provoking. 

 There would seem to be clear biases in some of the positions - for
instance, the statement that we overvalue individual structures and that
there is value only in their ensemble has to be seen to be coming from
someone in a structural genomics centre ;-) . However, as Wladek pointed
out, when an investigator's project is crucially dependent on a result
embodied in a deposited structure, it would be of the greatest value to that
investigator to be able to double-check how reliable some features of that
structure (especially its ligands) actually are.

 On the other hand Enrico, as a specialist of crystallisation and
modelling, sees value only in improving those contributors to the task of
structure determination. This is forgetting (1) an essential capability of
crystallography: that, through experimental phasing, it can show you what a
protein looks like even if you have never seen nor modelled one before,
through the wondrous process of producing model-free electron-density maps;
and (2) an essential aspect of the task of structure determination: that it
doesn't aim at producing a model with perfect geometry, but one that best
explains the measured data and neither under- nor over-interprets them (I
realise, though, that Enrico's statement "Data just introduces experimental
errors into what would otherwise be a perfect structure" is likely to be
tongue-in-cheek ...). 

 When it comes to making explicit the advantages of archiving at least
the raw images that yielded the data against which a deposited PDB entry was
refined, many good reasons have been given, but I feel that 

 (1) there is an over-emphasis on the preservation of diffuse scattering
that has a tendency to give this archiving a nuance of "blue-skies" research
and thus to detract from its practical urgency; time will come for diffuse
scattering to be fully appreciated, but at the moment its mention acts as a
bit of a distraction, if not a turn-off in this context for people who not
not love it already;

 (2) as far as I see it, the highest future benefit of having archived
raw images will result from being able to reprocess datasets from samples
containing multiple lattices ("non-merohedral twinning"). Numerous
structures are determined and refined against data obtained by integrating
only the spots from the major lattice, without rejecting those that are
corrupted by overlap by a spot from a minor lattice. This leads to
systematic errors in these data that may only be incompletely taken out by
outlier rejection at the merging stage, and will create noise or confusing
residual features in difference maps, if not false features in the main map
and therefore its interpretation by the model. In my opinion it will be the
development of methods for dealing with overlapped lattices and for the
proper treatment of such data in scaling and refinement (as is already
possible with small molecules) that will bring about the major possibility
of substantially improving deposited results by reprocessing the raw images
co-deposited with them;

 (3) there is also the more immediate possibility of better removing ice
rings, or ligand powder rings, from images, than by having to throw away
certain thin shells of merged data in the structure factor file.

 I see the case for raw image deposition as absolutely compelling,
especially in view of the auto-catalytic process through which their
availability will speed up the development of precisely the new methods and
software to extract better data from them and better refine models against
them. The impact of structure factor deposition on the development of better
refinement programs is there to prove that this paradigm of a chain reaction
makes total sense.

 Various arguments tend to be fired off as decoys - "get better
crystals", why not "get a better post-doc"? - but they are unhelpful in the
way they prolong procrastination when what we need is to bite the bullet.
The IUCr Forum that John Helliwell pointed at already contains draft plans
for a pilot run of a reasonable scheme.


 With best wishes,
 
  Gerard.

--
On Tue, Oct 18, 2011 at 06:19:27PM +0200, Enrico Stura wrote:
> Dear Peter,
>
> How many crystallographers does it take to transform bad data into good 
> data?
> None, you need a modeller. Only a modeller can give you a structure with 
> perfect
> geometry. Data just introduces experimental errors into what would 
> otherwise be a perfect
> structure.
>
> If you have good data do you need crystallographers?
> ...
>
> Of course there all the cases in between. That ... you are right, is the 
> other half of the story.
>
> From a biological point of view, only borderline cases make "cents" ($+€) 
> to store.
> T

Re: [ccp4bb] IUCr committees, depositing images

[Phoebe Rice]

One more consideration:
Since organization is not one of my greatest talents, I would be absolutely 
delighted if a databank took over the burden of archiving my raw data for me.  
  Phoebe

=
Phoebe A. Rice
Dept. of Biochemistry & Molecular Biology
The University of Chicago
phone 773 834 1723
http://bmb.bsd.uchicago.edu/Faculty_and_Research/01_Faculty/01_Faculty_Alphabetically.php?faculty_id=123
http://www.rsc.org/shop/books/2008/9780854042722.asp


 Original message 
>Date: Tue, 18 Oct 2011 18:17:14 +0100
>From: CCP4 bulletin board  (on behalf of Gerard 
>Bricogne )
>Subject: Re: [ccp4bb] IUCr committees, depositing images  
>To: CCP4BB@JISCMAIL.AC.UK
>
>Dear Enrico, Frank and colleagues,
>
> I am glad to have suggested that everyone's views on this issue should
>be aired out on this BB rather than sent off-list to an IUCr committee
>member: this is much more interactive and thought-provoking. 
>
> There would seem to be clear biases in some of the positions - for
>instance, the statement that we overvalue individual structures and that
>there is value only in their ensemble has to be seen to be coming from
>someone in a structural genomics centre ;-) . However, as Wladek pointed
>out, when an investigator's project is crucially dependent on a result
>embodied in a deposited structure, it would be of the greatest value to that
>investigator to be able to double-check how reliable some features of that
>structure (especially its ligands) actually are.
>
> On the other hand Enrico, as a specialist of crystallisation and
>modelling, sees value only in improving those contributors to the task of
>structure determination. This is forgetting (1) an essential capability of
>crystallography: that, through experimental phasing, it can show you what a
>protein looks like even if you have never seen nor modelled one before,
>through the wondrous process of producing model-free electron-density maps;
>and (2) an essential aspect of the task of structure determination: that it
>doesn't aim at producing a model with perfect geometry, but one that best
>explains the measured data and neither under- nor over-interprets them (I
>realise, though, that Enrico's statement "Data just introduces experimental
>errors into what would otherwise be a perfect structure" is likely to be
>tongue-in-cheek ...). 
>
> When it comes to making explicit the advantages of archiving at least
>the raw images that yielded the data against which a deposited PDB entry was
>refined, many good reasons have been given, but I feel that 
>
> (1) there is an over-emphasis on the preservation of diffuse scattering
>that has a tendency to give this archiving a nuance of "blue-skies" research
>and thus to detract from its practical urgency; time will come for diffuse
>scattering to be fully appreciated, but at the moment its mention acts as a
>bit of a distraction, if not a turn-off in this context for people who not
>not love it already;
>
> (2) as far as I see it, the highest future benefit of having archived
>raw images will result from being able to reprocess datasets from samples
>containing multiple lattices ("non-merohedral twinning"). Numerous
>structures are determined and refined against data obtained by integrating
>only the spots from the major lattice, without rejecting those that are
>corrupted by overlap by a spot from a minor lattice. This leads to
>systematic errors in these data that may only be incompletely taken out by
>outlier rejection at the merging stage, and will create noise or confusing
>residual features in difference maps, if not false features in the main map
>and therefore its interpretation by the model. In my opinion it will be the
>development of methods for dealing with overlapped lattices and for the
>proper treatment of such data in scaling and refinement (as is already
>possible with small molecules) that will bring about the major possibility
>of substantially improving deposited results by reprocessing the raw images
>co-deposited with them;
>
> (3) there is also the more immediate possibility of better removing ice
>rings, or ligand powder rings, from images, than by having to throw away
>certain thin shells of merged data in the structure factor file.
>
> I see the case for raw image deposition as absolutely compelling,
>especially in view of the auto-catalytic process through which their
>availability will speed up the development of precisely the new methods and
>software to extract better data from them and better refine models against
>them. The impact of structure factor deposition on the development of better
>refinement programs is there to prove that this paradigm of a chain reaction
>makes total sense.
>
> Various arguments tend to be fired off as decoys - "get better
>crystals", why not "get a better post-doc"? - but they are unhelpful in the
>way they prolong procrastination when what we need is to bite the bullet.
>The IU

Re: [ccp4bb] IUCr committees, depositing images

[Ed Pozharski]

On Tue, 2011-10-18 at 18:17 +0100, Gerard Bricogne wrote:
> it would be of the greatest value to that
> investigator to be able to double-check how reliable some features of
> that
> structure (especially its ligands) actually are. 

Certainly, one could argue here that the current PDB policy that
requires the deposition of the processed data already provides that
option.  I must add though that I find it disturbingly easy to
manipulate the Fo's to produce any ligand anywhere and generate a fake
dataset that is essentially impossible to detect as such.  It is only a
matter of time until someone under pressure does this, in all
likelihood, this might have already happened.  True, diffraction images
can also be ultimately manipulated, but that requires much higher level
of sophistication, and the hope is that individuals capable of such feat
have better things to do with their skills.

It seems to me that the cost of storage is so cheap these days that even
if reducing the chances of another retraction disaster is the only
benefit, it is worth it.  There are many other reasons why the benefits
of image deposition outweigh the costs, which reminds me of an old joke:

- Colonel, why your cannons did not fire?
- General, there were five reasons.  First, we had no gunpowder,
second...
- This one is enough!

Cheers,

Ed.

-- 
Oh, suddenly throwing a giraffe into a volcano to make water is crazy?
Julian, King of Lemurs

Re: [ccp4bb] IUCr committees, depositing images

[mjvdwoerd]

 Phoebe,

Just automate the archiving and come up with a reasonable scheme how to. Ours 
is that data sets are called:

userid_yearmonth_projectid_#

Userid is derived from the login into CrystalClear (oops, free advertizing), 
projectid is set by the PI (so she can remember 10 years from now what in the 
world these data are all about) and the users are asked (threatened) to call 
their data sets "projectid_#" (and not the ubiquitous "test"). We have a script 
that automatically archives everything away from our data collection computer 
into an archive - activated by an icon on the desktop - and it adds the userid 
and date to the filename. This has the nice added advantage that the data 
collection disk stays clean. This only breaks when we collect synchrotron data 
(which is all the time) because our synchrotron remote scientist who collects 
the data cannot (should not) be threatened. :-) I then rename all data sets for 
archiving so the naming is consistent and you can actually make (say in pdf) an 
index of all the data you have, organized by user, date, or project. 

Our policy is that the PI decides if data should be maintained or if it really 
can go (no diffraction, really a test crystal to see that the crystal is in the 
beam etc). In practice this doesn't happen so someone else makes the decision. 
We tend to err on the side of caution. We tend to think that all results should 
be saved, unless it is blatantly obvious that there is no point. Storage is 
cheap (and cheaper every time you think of it).

After you automate in the previously agreed upon scheme, it is somewhat easier 
to find things back because if you can remember who collected it, or 
approximately when it was done, or what the project was, you can find it. The 
pain was up front: to come up with a scheme, to enable a rigorous naming 
convention and to implement it (data collection computer and archive are not 
physically on the same computer etc). 

Maybe the Committee is also thinking about that issue - how are you going to 
keep all the data manageable and searchable. Presumably by something like a PDB 
id (this seems to make sense for published/deposited structures) but for 
"things that did not make it to PDB" one would have to come up with another 
plan.

Mark

 

 

-Original Message-
From: Phoebe Rice 
To: CCP4BB 
Sent: Tue, Oct 18, 2011 12:01 pm
Subject: Re: [ccp4bb] IUCr committees, depositing images


One more consideration:
Since organization is not one of my greatest talents, I would be absolutely 
delighted if a databank took over the burden of archiving my raw data for me.  
  Phoebe

=
Phoebe A. Rice
Dept. of Biochemistry & Molecular Biology
The University of Chicago
phone 773 834 1723
http://bmb.bsd.uchicago.edu/Faculty_and_Research/01_Faculty/01_Faculty_Alphabetically.php?faculty_id=123
http://www.rsc.org/shop/books/2008/9780854042722.asp


 Original message 
>Date: Tue, 18 Oct 2011 18:17:14 +0100
>From: CCP4 bulletin board  (on behalf of Gerard 
>Bricogne 
)
>Subject: Re: [ccp4bb] IUCr committees, depositing images  
>To: CCP4BB@JISCMAIL.AC.UK
>
>Dear Enrico, Frank and colleagues,
>
> I am glad to have suggested that everyone's views on this issue should
>be aired out on this BB rather than sent off-list to an IUCr committee
>member: this is much more interactive and thought-provoking. 
>
> There would seem to be clear biases in some of the positions - for
>instance, the statement that we overvalue individual structures and that
>there is value only in their ensemble has to be seen to be coming from
>someone in a structural genomics centre ;-) . However, as Wladek pointed
>out, when an investigator's project is crucially dependent on a result
>embodied in a deposited structure, it would be of the greatest value to that
>investigator to be able to double-check how reliable some features of that
>structure (especially its ligands) actually are.
>
> On the other hand Enrico, as a specialist of crystallisation and
>modelling, sees value only in improving those contributors to the task of
>structure determination. This is forgetting (1) an essential capability of
>crystallography: that, through experimental phasing, it can show you what a
>protein looks like even if you have never seen nor modelled one before,
>through the wondrous process of producing model-free electron-density maps;
>and (2) an essential aspect of the task of structure determination: that it
>doesn't aim at producing a model with perfect geometry, but one that best
>explains the measured data and neither under- nor over-interprets them (I
>realise, though, that Enrico's statement "Data just introduces experimental
>errors into what would otherwise be a perfect structure" is likely to be
>tongue-in-cheek ...). 
>
> When it comes to making explicit the advantages of archiving at least
>the raw images that yielded the data against which a deposited PDB entry was
>refined, many good

Re: [ccp4bb] should the final model be refined against full datset

[Ed Pozharski]

> Selecting a test set that minimizes Rfree is so wrong on so many levels.
> Unless, of course, the only thing I know about Rfree is that it is the
> magic number that I need to make small by all means necessary.

By using a simple genetic algorithm, I managed to get Rfree for a
well-refined model as low as 14.6% and as high as 19.1%.  The dataset is
not too small (~40,000 reflection in all with the standard sized 5% test
set).  So you can get spread as wide as 4.5% even with not-so-small
dataset.  Only ~1/3 of test reflections are exchanged to achieve this.

What's curious is that, contrary to my expectations, the test set
remains well distributed throughout resolution shells upon this awful
"optimization" and the  for the working set and test set remain
close.  Not sure how to judge which model is actually better, but it's
noteworthy that the FOM gets worse for *both* upward and downward
"optimization" of the test set.


-- 
After much deep and profound brain things inside my head, 
I have decided to thank you for bringing peace to our home.
Julian, King of Lemurs

[ccp4bb] Cell Params as a Function of Temperature

[Jacob Keller]

Dear Crystallographers,

is anyone aware of references studying variation in cell params
systematically as a function of temperature, with many points on the
curve (not just RT and 100K?)

Jacob Keller
-- 
***
Jacob Pearson Keller
Northwestern University
Medical Scientist Training Program
email: j-kell...@northwestern.edu
***

Re: [ccp4bb] Cell Params as a Function of Temperature

[Bryan Lepore]

On Tue, Oct 18, 2011 at 5:01 PM, Jacob Keller
 wrote:
> references studying variation in cell params
> systematically as a function of temperature, with many points on the
> curve (not just RT and 100K?)

a well cited article, from 1992:

Effects of temperature on protein structure and dynamics: x-ray
crystallographic studies of the protein ribonuclease-A at nine
different temperatures from 98 to 320K

Robert F. Tilton Jr., John C. Dewan, Gregory A. Petsko
Biochemistry, 1992, 31 (9), pp 2469–2481

http://pubs.acs.org/doi/abs/10.1021/bi00124a006

[ccp4bb] newbie question about data processing

[Edward A. Berry]

I integrated data with mosflm using the lowest symmetry implied by
the lattice- P4. Scaling with scala confirms that symmetry.
Now I want to test P422, but scala doesn't seem to have a SYMM
or SPACE GROUP keyword. I'm sure there is an obvious way to do
this, which everyone else knows, but i don't see it.

I understand that pointless can be inserted between mosflm
and scala to decide and change space group. Unfortunately
I built ccp4 without cctbx, phaser and pointless (phaser is
installed separately) so I don't have pointless. I'm
trying to get it installed now but if there is another way
to rescale the batches with higher symmetry I would like
to try it.

Ed

Re: [ccp4bb] newbie question about data processing

[Harry]

Hi Ed

"reindex" is your friend here -

reindex hklin jumbo.mtz hklout dumbo.mtz <
I integrated data with mosflm using the lowest symmetry implied by
the lattice- P4. Scaling with scala confirms that symmetry.
Now I want to test P422, but scala doesn't seem to have a SYMM
or SPACE GROUP keyword. I'm sure there is an obvious way to do
this, which everyone else knows, but i don't see it.

I understand that pointless can be inserted between mosflm
and scala to decide and change space group. Unfortunately
I built ccp4 without cctbx, phaser and pointless (phaser is
installed separately) so I don't have pointless. I'm
trying to get it installed now but if there is another way
to rescale the batches with higher symmetry I would like
to try it.

Ed


Harry
--
Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre,  
Hills Road, Cambridge, CB2 0QH

Re: [ccp4bb] newbie question about data processing

[Edward A. Berry]

Thanks! That does it.

Harry wrote:

Hi Ed

"reindex" is your friend here -

reindex hklin jumbo.mtz hklout dumbo.mtz <
I integrated data with mosflm using the lowest symmetry implied by
the lattice- P4. Scaling with scala confirms that symmetry.
Now I want to test P422, but scala doesn't seem to have a SYMM
or SPACE GROUP keyword. I'm sure there is an obvious way to do
this, which everyone else knows, but i don't see it.

I understand that pointless can be inserted between mosflm
and scala to decide and change space group. Unfortunately
I built ccp4 without cctbx, phaser and pointless (phaser is
installed separately) so I don't have pointless. I'm
trying to get it installed now but if there is another way
to rescale the batches with higher symmetry I would like
to try it.

Ed


Harry
--
Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre,
Hills Road, Cambridge, CB2 0QH

Re: [ccp4bb] IUCr committees, depositing images

[Bosch, Juergen]

What do you consider good ? r.m.s.d of 2.5 Å ? fatal for drug design.

On Oct 18, 2011, at 12:19 PM, Enrico Stura wrote:

Dear Peter,

How many crystallographers does it take to transform bad data into good
data?
None, you need a modeller. Only a modeller can give you a structure with
perfect
geometry. Data just introduces experimental errors into what would
otherwise be a perfect
structure.

If you have good data do you need crystallographers?
No just the right programs. Which brings us back to the hypothetical question 
of why do we care ? I mean more precisely the question each of us is trying to 
answer in their own research program.

Crystallography is a high-end tool, not quite as simple as a western blot or 
ELISA but in the end it's just a tool to answer some critical questions.

Jürgen


..
Jürgen Bosch
Johns Hopkins University
Bloomberg School of Public Health
Department of Biochemistry & Molecular Biology
Johns Hopkins Malaria Research Institute
615 North Wolfe Street, W8708
Baltimore, MD 21205
Office: +1-410-614-4742
Lab:  +1-410-614-4894
Fax:  +1-410-955-2926
http://web.mac.com/bosch_lab/

Re: [ccp4bb] IUCr committees, depositing images

[Felix Frolow]

Sure they will
There is no irony in what I say
FF
Dr Felix Frolow   
Professor of Structural Biology and Biotechnology
Department of Molecular Microbiology
and Biotechnology
Tel Aviv University 69978, Israel

Acta Crystallographica F, co-editor

e-mail: mbfro...@post.tau.ac.il
Tel:  ++972-3640-8723
Fax: ++972-3640-9407
Cellular: 0547 459 608

On Oct 18, 2011, at 20:01 , Phoebe Rice wrote:

> One more consideration:
> Since organization is not one of my greatest talents, I would be absolutely 
> delighted if a databank took over the burden of archiving my raw data for me. 
>  
>  Phoebe
> 
> =
> Phoebe A. Rice
> Dept. of Biochemistry & Molecular Biology
> The University of Chicago
> phone 773 834 1723
> http://bmb.bsd.uchicago.edu/Faculty_and_Research/01_Faculty/01_Faculty_Alphabetically.php?faculty_id=123
> http://www.rsc.org/shop/books/2008/9780854042722.asp
> 
> 
>  Original message 
>> Date: Tue, 18 Oct 2011 18:17:14 +0100
>> From: CCP4 bulletin board  (on behalf of Gerard 
>> Bricogne )
>> Subject: Re: [ccp4bb] IUCr committees, depositing images  
>> To: CCP4BB@JISCMAIL.AC.UK
>> 
>> Dear Enrico, Frank and colleagues,
>> 
>>I am glad to have suggested that everyone's views on this issue should
>> be aired out on this BB rather than sent off-list to an IUCr committee
>> member: this is much more interactive and thought-provoking. 
>> 
>>There would seem to be clear biases in some of the positions - for
>> instance, the statement that we overvalue individual structures and that
>> there is value only in their ensemble has to be seen to be coming from
>> someone in a structural genomics centre ;-) . However, as Wladek pointed
>> out, when an investigator's project is crucially dependent on a result
>> embodied in a deposited structure, it would be of the greatest value to that
>> investigator to be able to double-check how reliable some features of that
>> structure (especially its ligands) actually are.
>> 
>>On the other hand Enrico, as a specialist of crystallisation and
>> modelling, sees value only in improving those contributors to the task of
>> structure determination. This is forgetting (1) an essential capability of
>> crystallography: that, through experimental phasing, it can show you what a
>> protein looks like even if you have never seen nor modelled one before,
>> through the wondrous process of producing model-free electron-density maps;
>> and (2) an essential aspect of the task of structure determination: that it
>> doesn't aim at producing a model with perfect geometry, but one that best
>> explains the measured data and neither under- nor over-interprets them (I
>> realise, though, that Enrico's statement "Data just introduces experimental
>> errors into what would otherwise be a perfect structure" is likely to be
>> tongue-in-cheek ...). 
>> 
>>When it comes to making explicit the advantages of archiving at least
>> the raw images that yielded the data against which a deposited PDB entry was
>> refined, many good reasons have been given, but I feel that 
>> 
>>(1) there is an over-emphasis on the preservation of diffuse scattering
>> that has a tendency to give this archiving a nuance of "blue-skies" research
>> and thus to detract from its practical urgency; time will come for diffuse
>> scattering to be fully appreciated, but at the moment its mention acts as a
>> bit of a distraction, if not a turn-off in this context for people who not
>> not love it already;
>> 
>>(2) as far as I see it, the highest future benefit of having archived
>> raw images will result from being able to reprocess datasets from samples
>> containing multiple lattices ("non-merohedral twinning"). Numerous
>> structures are determined and refined against data obtained by integrating
>> only the spots from the major lattice, without rejecting those that are
>> corrupted by overlap by a spot from a minor lattice. This leads to
>> systematic errors in these data that may only be incompletely taken out by
>> outlier rejection at the merging stage, and will create noise or confusing
>> residual features in difference maps, if not false features in the main map
>> and therefore its interpretation by the model. In my opinion it will be the
>> development of methods for dealing with overlapped lattices and for the
>> proper treatment of such data in scaling and refinement (as is already
>> possible with small molecules) that will bring about the major possibility
>> of substantially improving deposited results by reprocessing the raw images
>> co-deposited with them;
>> 
>>(3) there is also the more immediate possibility of better removing ice
>> rings, or ligand powder rings, from images, than by having to throw away
>> certain thin shells of merged data in the structure factor file.
>> 
>>I see the case for raw image deposition as absolutely compelling,
>> especially in view of the auto-catalytic process through which their
>> availability 

Re: [ccp4bb] buccaneer_pipeline failure (ccp4 6.2.0) (SOLUTION)

[Frank von Delft]

We discovered the problem:  the file $CBIN/buccaneer_pipeline needs to 
be told to expand its lookup path, so we inserted in the 2nd line:


sys.path.append("/usr/local/ccp4/6.2.0/ccp4-6.2.0/share/python/")

We had this fix in our previous installation as well, but can't remember 
where we got it from;  I have no idea why only we seem to need it (is 
nobody else running buccaneer?  Then they're fools:  it's massively 
useful...)


Cheers
phx


On 18/10/2011 10:52, Tim Gruene wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

And you do have read access to
/usr/local/ccp4/6.2.0/ccp4-6.2.0/share/python/CCP4pipeline.py
(on our installation, the mode is actually 755, but I suppose 644 should
be sufficient).
You can set PYTHONVERBOSE to 1 or higher in the shell you start ccp4i
from to see what python is doing ('man python').

Tim

On 10/18/2011 11:34 AM, Frank von Delft wrote:

Mine reads:
/usr/local/ccp4/6.2.0/ccp4-6.2.0/share/python:/usr/local/ccpnmr/ccpnmr1.0/python


That should work, right?  Where else can I look, for the failing
import?  This is a lettuce-fresh install, pulled straight off web and
installed with all defaults.

Cheers
phx.


On 18/10/2011 08:38, Tim Gruene wrote:
Hi Frank,

it may not be the python binary itself but the PYTHONPATH which is
incorrectly set. After initialising ccp4, mine reads
 tg@slartibartfast:~$ echo $PYTHONPATH
 /xtal/Suites/CCP4/ccp4-6.2.0/share/python:
which is modified around line 231 in $CBIN/include/ccp4.setup

My python binary is /usr/bin/python, and I have used buccaneer without
errors.

Tim



On 10/17/2011 09:30 PM, Frank von Delft wrote:

Hi, we got around to switching to ccp4 version 6.2.0, but now buccaneer
fails from the GUI.  Below is what shows up if you view the com file
before execution; and below that the logfile.

Seems to me it's using the wrong python executable;  the first one on my
path is certainly nothing to do with ccp4, so now wonder it can't
import.

Shouldn't python be invoked explicitly with its full path?  Where can I
set this?  (Mind you, setting it in the Run&View didn't work.)
Cheers
phx




*Run&View Com File: *
python -u /usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline -stdin


*Logfile*
#CCP4I VERSION CCP4Interface 2.1.0
#CCP4I SCRIPT LOG buccaneer_pipeline
#CCP4I DATE 17 Oct 2011  18:45:20
#CCP4I USER loretta
#CCP4I PROJECT PROJECT
#CCP4I JOB_ID 13
#CCP4I SCRATCH /tmp/loretta
#CCP4I HOSTNAME hestia.sgc.ox.ac.uk
#CCP4I PID 13684

***

* Information from CCP4Interface script
***

The program run with command: python -u
/usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline -stdin
has failed with error message
Traceback (most recent call last):
File "/usr/local/ccp4/6.2.0/ccp4-6.2.0/bin/buccaneer_pipeline", line
3, in
  from CCP4pipeline import Control
ImportError: No module named CCP4pipeline
***




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

GPG Key ID = A46BEE1A

- -- 
- --

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

GPG Key ID = A46BEE1A

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOnUw9UxlJ7aRr7hoRAiREAKCgr2dJMVtNPi4BZKnzMqoJw5O/GwCgw1Pb
XrR2jUbn0oGsPL6W+PdyGiA=
=BS9b
-END PGP SIGNATURE-