[ccp4bb] DLS

[Mohd Shukuri Mohamad Ali]

Hi there

Sorry for the off ccp4 topics. I am planning to get a DLS to set up my
crystallography lab. I got a tight budget. Around USD 8 perhaps. I'm
quite new to this field.

Thanks in advance for your suggestions

Regards
Shukuri

Re: [ccp4bb] resolution limit stuck in Refmac5

[Nat Echols]

On Fri, Oct 29, 2010 at 5:46 PM, Tom Huxford wrote:

> I'm working with good quality relatively complete x-ray diffraction data
> collected to a resolution limit 2.6 Å from a crystal of a protein with a
> small molecule ligand bound.  I ran MR from 10-4 Å and then did maximum
> likelihood rigid body refinement in Refmac5 against data from 50-3.5 Å.  Now
> I would like to run restrained refinement from 50-3 Å.  The reason for doing
> this is that, in order to minimize the divergence between R-cryst and R-free
> during refinement my advisor who, by the way, is forwarding this e-mail for
> me (and editing it so please don't bash him too mercilessly) suggested I
> first build in the ligand and newly positioned polypeptide loops and refine
> against data at a lower resolution limit before opening it up to all the
> available data.  Apparently this has worked well for him in the past (and it
> has!).  The problem is that I'm to the point where I'd like to extend the
> resolution down to 3 Å during restrained refinement but even if I set the
> range from 50-3 Å in the ccp4i window refinement only happens from 50-3.5
> Å.  If I take a step back and do the rigid body refinement from 50-3 Å and
> then carry out restrained refinement from 50-3 Å it works fine.  Why would
> the limits imposed by rigid body refinement cause the subsequent restrained
> refinement to be stuck at the rigid body refinement's resolution limits?
>

Did you refine against the file output by Refmac after rigid-body
refinement, instead of using the original reflections?

-Nat

[ccp4bb] resolution limit stuck in Refmac5

[Tom Huxford]

Hi all,

I'm working with good quality relatively complete x-ray diffraction 
data collected to a resolution limit 2.6 Å from a crystal of a protein 
with a small molecule ligand bound.  I ran MR from 10-4 Å and then did 
maximum likelihood rigid body refinement in Refmac5 against data from 
50-3.5 Å.  Now I would like to run restrained refinement from 50-3 Å.  
The reason for doing this is that, in order to minimize the divergence 
between R-cryst and R-free during refinement my advisor who, by the 
way, is forwarding this e-mail for me (and editing it so please don't 
bash him too mercilessly) suggested I first build in the ligand and 
newly positioned polypeptide loops and refine against data at a lower 
resolution limit before opening it up to all the available data.  
Apparently this has worked well for him in the past (and it has!).  The 
problem is that I'm to the point where I'd like to extend the 
resolution down to 3 Å during restrained refinement but even if I set 
the range from 50-3 Å in the ccp4i window refinement only happens from 
50-3.5 Å.  If I take a step back and do the rigid body refinement from 
50-3 Å and then carry out restrained refinement from 50-3 Å it works 
fine.  Why would the limits imposed by rigid body refinement cause the 
subsequent restrained refinement to be stuck at the rigid body 
refinement's resolution limits?


Thanks for any thoughts,

Jon Fleming
Graduate Student
Structural Biochemistry Laboratory (Huxford Lab)
Department of Chemistry & Biochemistry
San Diego State University

Re: [ccp4bb] Strange spots

[Edward Snell]

They remind me of the fiber bundle on optic taper between the phosphor and the 
CCD.  That's from things I saw years ago (BC - before crystallography) and I 
don't know the system in use here. I suspect it's instrumental and any 
diffraction in that area of the detector should show similar effects if there 
is a reflection there. Have you checked more images?

This also gave me a great excuse to break out my newly arrived Atlas of Optical 
Transforms (thanks A.) and look at some more exotic explanations :)  $5 from 
Amazon. Consider a spherical crystal  :)

Cheers,

Eddie.

From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of James 
Holton
Sent: Friday, October 29, 2010 7:04 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Strange spots


The shape reminds me of the focused beam spot profile from slightly misaligned 
capillary optics.  I don't have too much experience with these, but the 
incident beam profile does tend to "propagate" through to the spots on the 
detector.

I wonder, could what you are seeing be a "halo" of minor incident beams, all 
converging on the sample, but at very different angles from the main beam.  
what you would see then is a "circle" of diffraction patterns around the usual 
pattern, but each at effectively a different crystal orientation (because the 
"halo" beams come in at different angles).  This would explain why the effect 
only seems to be apparent for spots that are close to (but not "at") the Bragg 
condition.

What kind of x-ray setup is this?

-James Holton
MAD Scientist

On 10/29/2010 9:08 AM, David Goldstone wrote:
Dear All,

Does anyone have any insight into what the circles around the spots might be?

cheers

Dave

Re: [ccp4bb] Strange spots

[James Holton]

The shape reminds me of the focused beam spot profile from slightly
misaligned capillary optics.  I don't have too much experience with these,
but the incident beam profile does tend to "propagate" through to the spots
on the detector.

I wonder, could what you are seeing be a "halo" of minor incident beams, all
converging on the sample, but at very different angles from the main beam.
what you would see then is a "circle" of diffraction patterns around the
usual pattern, but each at effectively a different crystal orientation
(because the "halo" beams come in at different angles).  This would explain
why the effect only seems to be apparent for spots that are close to (but
not "at") the Bragg condition.

What kind of x-ray setup is this?

-James Holton
MAD Scientist

On 10/29/2010 9:08 AM, David Goldstone wrote:

Dear All,

Does anyone have any insight into what the circles around the spots might
be?

cheers

Dave

Re: [ccp4bb] Strange spots

[Julian Nomme]

Kris,
the link works for me and obviously for other people. I don't know why 
you don't have access to it...

Anyway, thank you Konstantin for providing the pdf!

Julian

On 10/29/10 4:17 PM, Konstantin v. Korotkov wrote:

The link worked for me, pages 320-322 attached.

-Konstantin


On Fri, 29 Oct 2010, Gerard Bricogne wrote:


Dear Liz,

You will be disappointed. I went immediately to that link, but 
page 321
is not available as part of the Googlebook sample, which jumps 
directly from

page 320 to page 325.


With best wishes,

 Gerard.

--
On Fri, Oct 29, 2010 at 09:13:27PM +0100, 
elizabeth.d...@diamond.ac.uk wrote:

There is always hope!!!

Seriously though, I have never seen anything like this before! I am 
watching this thread with interest to see what others suggest.


THanks Also thanks should go specifically to Julian Nomme who took 
the trouble to send us all the Helliwell book  link.


Liz



From: CCP4 bulletin board on behalf of Sanishvili, Ruslan
Sent: Fri 29/10/2010 21:08
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Strange spots



C'mon now! Everybody knows that frogs in real space become handsome 
princes in the reciprocal one...


N.



Ruslan Sanishvili (Nukri), Ph.D.

GM/CA-CAT
Biosciences Division, ANL
9700 S. Cass Ave.
Argonne, IL 60439

Tel: (630)252-0665
Fax: (630)252-0667
rsanishv...@anl.gov



From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf 
Of Jacob Keller

Sent: Friday, October 29, 2010 3:00 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Strange spots





Yes, but the question is what in real space gives rise to 
reciprocal-space frog spawn? (Frogs, I guess?)




- Original Message -

From: Marcus Winter 

To: CCP4BB@JISCMAIL.AC.UK

Sent: Friday, October 29, 2010 2:56 PM

Subject: Re: [ccp4bb] Strange spots









Dear David,





Further to the previous learned responses, surely, this

is just frog spawn ?



My apologies: it is a Friday evening, after all...





Marcus Winter.







-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On 
Behalf Of David Goldstone

Sent: 29 October 2010 17:08
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] Strange spots



Dear All,



Does anyone have any insight into what the circles around the 
spots might be?




cheers



Dave

--

David Goldstone, PhD

National Institute for Medical Research

Molecular Structure

The Ridgeway

Mill Hill

London NW7 1AA







***
Jacob Pearson Keller
Northwestern University
Medical Scientist Training Program
Dallos Laboratory
F. Searle 1-240
2240 Campus Drive
Evanston IL 60208
lab: 847.491.2438
cel: 773.608.9185
email: j-kell...@northwestern.edu
***




--
Konstantin Korotkov, Ph.D.

Research Scientist
University of Washington
Department of Biochemistry
Box 357742
Seattle, WA 98195-7742

(206)616-4512
k...@u.washington.edu
--

Re: [ccp4bb] Strange spots

[Jim Pflugrath]

Are these very strong reflections?  Do they appear on more than one image?

Are they an artefact of the detector or the image display program?

Re: [ccp4bb] Strange spots

[Bart Hazes]

Hi Dave,

The circles are quite prominent in the "inner circle (lune)" that you 
highlight but not in the next one. The full image is too small to see 
details but I don't see any clear circular halos for any of the other 
lunes. If you start with the lune going through the origin and number it 
zero, then the one with the halos is lune 7. Any chance that there is a 
pseudo translation with a periodicity of ~1/7th of the reciprocal vector 
perpendicular to the planes that form the lunes.


The pseudo-2D lattice with the halos suggest 
hexagonal/trigonal/rhombohedral lattice and the halo radius is half the 
reciprocal unit cell length. Maybe you have some weird stacked 
rhombohedral packing where two or more rhombohedral cells intercalate so 
that there are pure rhombohedral unit cell axes that apply to all atoms 
and some pseudo translations that related an atom in one rhombohedral 
lattice to one in another stacked lattice. Don't know if that makes sense.


It would be interesting to see some images before and after this one. 
Are the halos circles in reciprocal space or spheres that just look like 
circles on the oscillation image because the intersection of a sphere 
with the Ewald sphere looks like a circle.
On images where the 6th, 5th etc lune forms a 2D lattice do you see the 
halo's or is it only on the 7th.


As John said you may well have a collectors item but it would sure be 
nice to know what caused this even if structure determination is not in 
the cards.


Bart

On 10-10-29 10:08 AM, David Goldstone wrote:

Dear All,

Does anyone have any insight into what the circles around the spots 
might be?


cheers

Dave


--



Bart Hazes (Associate Professor)
Dept. of Medical Microbiology&  Immunology
University of Alberta
1-15 Medical Sciences Building
Edmonton, Alberta
Canada, T6G 2H7
phone:  1-780-492-0042
fax:1-780-492-7521

Re: [ccp4bb] Strange spots

[Gerard Bricogne]

Dear Liz,

 You will be disappointed. I went immediately to that link, but page 321
is not available as part of the Googlebook sample, which jumps directly from
page 320 to page 325. 


 With best wishes,
 
  Gerard.

--
On Fri, Oct 29, 2010 at 09:13:27PM +0100, elizabeth.d...@diamond.ac.uk wrote:
> There is always hope!!!
>  
> Seriously though, I have never seen anything like this before! I am watching 
> this thread with interest to see what others suggest.
>  
> THanks Also thanks should go specifically to Julian Nomme who took the 
> trouble to send us all the Helliwell book  link. 
>  
> Liz
> 
> 
> 
> From: CCP4 bulletin board on behalf of Sanishvili, Ruslan
> Sent: Fri 29/10/2010 21:08
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Strange spots
> 
> 
> 
> C'mon now! Everybody knows that frogs in real space become handsome princes 
> in the reciprocal one...
> 
> N.
> 
>  
> 
> Ruslan Sanishvili (Nukri), Ph.D.
> 
> GM/CA-CAT
> Biosciences Division, ANL
> 9700 S. Cass Ave.
> Argonne, IL 60439
> 
> Tel: (630)252-0665
> Fax: (630)252-0667
> rsanishv...@anl.gov 
> 
> 
> 
> From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Jacob 
> Keller
> Sent: Friday, October 29, 2010 3:00 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Strange spots
> 
>  
> 
>  
> 
> Yes, but the question is what in real space gives rise to reciprocal-space 
> frog spawn? (Frogs, I guess?)
> 
>
> 
>   - Original Message - 
> 
>   From: Marcus Winter   
> 
>   To: CCP4BB@JISCMAIL.AC.UK 
> 
>   Sent: Friday, October 29, 2010 2:56 PM
> 
>   Subject: Re: [ccp4bb] Strange spots
> 
>
> 
>
> 
>
> 
>
> 
>   Dear David, 
> 
>
> 
>
> 
>   Further to the previous learned responses, surely, this 
> 
>   is just frog spawn ?
> 
>
> 
>   My apologies: it is a Friday evening, after all...
> 
>
> 
>
> 
>   Marcus Winter.
> 
>
> 
>
> 
>
> 
>   -Original Message-
>   From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of 
> David Goldstone
>   Sent: 29 October 2010 17:08
>   To: CCP4BB@JISCMAIL.AC.UK
>   Subject: [ccp4bb] Strange spots
> 
>
> 
>   Dear All,
> 
>
> 
>   Does anyone have any insight into what the circles around the spots 
> might be?
> 
>
> 
>   cheers
> 
>
> 
>   Dave
> 
>   --
> 
>   David Goldstone, PhD
> 
>   National Institute for Medical Research
> 
>   Molecular Structure
> 
>   The Ridgeway
> 
>   Mill Hill
> 
>   London NW7 1AA
> 
>
> 
>  
> 
>  
> 
> ***
> Jacob Pearson Keller
> Northwestern University
> Medical Scientist Training Program
> Dallos Laboratory
> F. Searle 1-240
> 2240 Campus Drive
> Evanston IL 60208
> lab: 847.491.2438
> cel: 773.608.9185
> email: j-kell...@northwestern.edu
> ***

Re: [ccp4bb] Strange spots

[Bryan Lepore]

On Fri, Oct 29, 2010 at 4:25 PM, Ethan Merritt  wrote:
> You may laugh, but the Google finds hits on the topic here:
>
>   http://atlas-conferences.com/cgi-bin/abstract/cauu-47

anyone who made complete sense of that abstract is invited to go here :

http://snarxiv.org/vs-arxiv/

and if you do, please let us know if you needed to apply the Ads/CFT
correspondence.

Re: [ccp4bb] Strange spots

[Van Den Berg, Bert]

Autoindexing in the truest sense of the word? ;-)


On 10/29/10 12:08 PM, "David Goldstone"  wrote:

Dear All,

Does anyone have any insight into what the circles around the spots
might be?

cheers

Dave
--
David Goldstone, PhD
National Institute for Medical Research
Molecular Structure
The Ridgeway
Mill Hill
London NW7 1AA

Re: [ccp4bb] Strange spots

[Ethan Merritt]

On Friday, October 29, 2010 12:59:40 pm Jacob Keller wrote:
> 
> Yes, but the question is what in real space gives rise to reciprocal-space 
> frog spawn? (Frogs, I guess?)

You may laugh, but the Google finds hits on the topic here:

   http://www.ph.surrey.ac.uk/newsite/ugrad_uploads/Lisowski2004May04100954.pdf

and here:

   
http://www.freshpatents.com/Manganese-ozone-decomposition-catalysts-and-process-for-its-preparation-dt20070315ptan20070060472.php?type=description

and here:

  http://atlas-conferences.com/cgi-bin/abstract/cauu-47 

Ethan

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: [ccp4bb] Strange spots

[elizabeth . duke]

There is always hope!!!
 
Seriously though, I have never seen anything like this before! I am watching 
this thread with interest to see what others suggest.
 
THanks Also thanks should go specifically to Julian Nomme who took the trouble 
to send us all the Helliwell book  link. 
 
Liz



From: CCP4 bulletin board on behalf of Sanishvili, Ruslan
Sent: Fri 29/10/2010 21:08
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Strange spots



C'mon now! Everybody knows that frogs in real space become handsome princes in 
the reciprocal one...

N.

 

Ruslan Sanishvili (Nukri), Ph.D.

GM/CA-CAT
Biosciences Division, ANL
9700 S. Cass Ave.
Argonne, IL 60439

Tel: (630)252-0665
Fax: (630)252-0667
rsanishv...@anl.gov 



From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Jacob 
Keller
Sent: Friday, October 29, 2010 3:00 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Strange spots

 

 

Yes, but the question is what in real space gives rise to reciprocal-space frog 
spawn? (Frogs, I guess?)

 

- Original Message - 

From: Marcus Winter   

To: CCP4BB@JISCMAIL.AC.UK 

Sent: Friday, October 29, 2010 2:56 PM

Subject: Re: [ccp4bb] Strange spots

 

 

 

 

Dear David, 

 

 

Further to the previous learned responses, surely, this 

is just frog spawn ?

 

My apologies: it is a Friday evening, after all...

 

 

Marcus Winter.

 

 

 

-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of 
David Goldstone
Sent: 29 October 2010 17:08
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] Strange spots

 

Dear All,

 

Does anyone have any insight into what the circles around the spots 
might be?

 

cheers

 

Dave

--

David Goldstone, PhD

National Institute for Medical Research

Molecular Structure

The Ridgeway

Mill Hill

London NW7 1AA

 

 

 

***
Jacob Pearson Keller
Northwestern University
Medical Scientist Training Program
Dallos Laboratory
F. Searle 1-240
2240 Campus Drive
Evanston IL 60208
lab: 847.491.2438
cel: 773.608.9185
email: j-kell...@northwestern.edu
***

Re: [ccp4bb] Strange spots

[Leiman Petr]

I think this is a poly-crystalline incommensurately modulated crystal, i.e.
incommensurately modulated crystal, which fractured upon freezing, resulting
in averaging of satellite spots.

Fig. 3b from here:
http://www.princeton.edu/~actin/documents/Proteincrystalscanbeincommensurate
lymodulated.pdf

Petr



On 10/29/10 6:08 PM, "David Goldstone" 
wrote:

> Dear All,
> 
> Does anyone have any insight into what the circles around the spots
> might be?
> 
> cheers
> 
> Dave

Re: [ccp4bb] Strange spots

[Jacob Keller]

Only when you do refinement(explains other thread about the unexplained 
R-gap)

JPK

  - Original Message - 
  From: Sanishvili, Ruslan 
  To: Jacob Keller ; CCP4BB@JISCMAIL.AC.UK 
  Sent: Friday, October 29, 2010 3:08 PM
  Subject: RE: [ccp4bb] Strange spots


  C'mon now! Everybody knows that frogs in real space become handsome princes 
in the reciprocal one.

  N.

   

  Ruslan Sanishvili (Nukri), Ph.D.

  GM/CA-CAT
  Biosciences Division, ANL
  9700 S. Cass Ave.
  Argonne, IL 60439

  Tel: (630)252-0665
  Fax: (630)252-0667
  rsanishv...@anl.gov 


--

  From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Jacob 
Keller
  Sent: Friday, October 29, 2010 3:00 PM
  To: CCP4BB@JISCMAIL.AC.UK
  Subject: Re: [ccp4bb] Strange spots

   

   

  Yes, but the question is what in real space gives rise to reciprocal-space 
frog spawn? (Frogs, I guess?)

 

- Original Message - 

From: Marcus Winter 

To: CCP4BB@JISCMAIL.AC.UK 

Sent: Friday, October 29, 2010 2:56 PM

Subject: Re: [ccp4bb] Strange spots

 

 

 

 

Dear David, 

 

 

Further to the previous learned responses, surely, this 

is just frog spawn ?

 

My apologies: it is a Friday evening, after all...

 

 

Marcus Winter.

 

 

 

-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of David 
Goldstone
Sent: 29 October 2010 17:08
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] Strange spots

 

Dear All,

 

Does anyone have any insight into what the circles around the spots might 
be?

 

cheers

 

Dave

--

David Goldstone, PhD

National Institute for Medical Research

Molecular Structure

The Ridgeway

Mill Hill

London NW7 1AA

 

   

   

  ***
  Jacob Pearson Keller
  Northwestern University
  Medical Scientist Training Program
  Dallos Laboratory
  F. Searle 1-240
  2240 Campus Drive
  Evanston IL 60208
  lab: 847.491.2438
  cel: 773.608.9185
  email: j-kell...@northwestern.edu
  ***




***
Jacob Pearson Keller
Northwestern University
Medical Scientist Training Program
Dallos Laboratory
F. Searle 1-240
2240 Campus Drive
Evanston IL 60208
lab: 847.491.2438
cel: 773.608.9185
email: j-kell...@northwestern.edu
***

Re: [ccp4bb] Strange spots

[Sanishvili, Ruslan]

C'mon now! Everybody knows that frogs in real space become handsome
princes in the reciprocal one...

N.

 

Ruslan Sanishvili (Nukri), Ph.D.

GM/CA-CAT
Biosciences Division, ANL
9700 S. Cass Ave.
Argonne, IL 60439

Tel: (630)252-0665
Fax: (630)252-0667
rsanishv...@anl.gov 



From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
Jacob Keller
Sent: Friday, October 29, 2010 3:00 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Strange spots

 

 

Yes, but the question is what in real space gives rise to
reciprocal-space frog spawn? (Frogs, I guess?)

 

- Original Message - 

From: Marcus Winter   

To: CCP4BB@JISCMAIL.AC.UK 

Sent: Friday, October 29, 2010 2:56 PM

Subject: Re: [ccp4bb] Strange spots

 

 

 

 

Dear David, 

 

 

Further to the previous learned responses, surely, this 

is just frog spawn ?

 

My apologies: it is a Friday evening, after all...

 

 

Marcus Winter.

 

 

 

-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On
Behalf Of David Goldstone
Sent: 29 October 2010 17:08
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] Strange spots

 

Dear All,

 

Does anyone have any insight into what the circles around the
spots might be?

 

cheers

 

Dave

--

David Goldstone, PhD

National Institute for Medical Research

Molecular Structure

The Ridgeway

Mill Hill

London NW7 1AA

 

 

 

***
Jacob Pearson Keller
Northwestern University
Medical Scientist Training Program
Dallos Laboratory
F. Searle 1-240
2240 Campus Drive
Evanston IL 60208
lab: 847.491.2438
cel: 773.608.9185
email: j-kell...@northwestern.edu
***

Re: [ccp4bb] Strange spots

[Jacob Keller]

Yes, but the question is what in real space gives rise to reciprocal-space frog 
spawn? (Frogs, I guess?)

  - Original Message - 
  From: Marcus Winter 
  To: CCP4BB@JISCMAIL.AC.UK 
  Sent: Friday, October 29, 2010 2:56 PM
  Subject: Re: [ccp4bb] Strange spots


   

   

   

  Dear David, 

   

   

  Further to the previous learned responses, surely, this 

  is just frog spawn ?

   

  My apologies: it is a Friday evening, after all...

   

   

  Marcus Winter.

   

   

   

  -Original Message-
  From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of David 
Goldstone
  Sent: 29 October 2010 17:08
  To: CCP4BB@JISCMAIL.AC.UK
  Subject: [ccp4bb] Strange spots

   

  Dear All,

   

  Does anyone have any insight into what the circles around the spots might be?

   

  cheers

   

  Dave

  --

  David Goldstone, PhD

  National Institute for Medical Research

  Molecular Structure

  The Ridgeway

  Mill Hill

  London NW7 1AA

   




***
Jacob Pearson Keller
Northwestern University
Medical Scientist Training Program
Dallos Laboratory
F. Searle 1-240
2240 Campus Drive
Evanston IL 60208
lab: 847.491.2438
cel: 773.608.9185
email: j-kell...@northwestern.edu
***

Re: [ccp4bb] Strange spots

[Marcus Winter]

Dear David,





Further to the previous learned responses, surely, this

is just frog spawn ?



My apologies: it is a Friday evening, after all...





Marcus Winter.







-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of David 
Goldstone
Sent: 29 October 2010 17:08
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] Strange spots



Dear All,



Does anyone have any insight into what the circles around the spots might be?



cheers



Dave

--

David Goldstone, PhD

National Institute for Medical Research

Molecular Structure

The Ridgeway

Mill Hill

London NW7 1AA

[ccp4bb] Which version CCP4 output DFc colume in SIGMAA?

[Hailiang Zhang]

Hi,

I remember the SIGMAA utility in some version of CCP4 can output DFC
colume in the mtz file. If somebody see this colume in you SIGMAA mtz
file, could you let me know which version CCP4 you are using? THanks!

Best Regards, Hailiang

Re: [ccp4bb] Strange spots

[Soisson, Stephen M]

Gerard,

I happen to have inherited a copy of Sir John's book from Joe Becker
some years ago.

Don't get your hopes up as the effect is apparently unexplained:

"No satisfactory explanation for these features has yet been found, but
they are probably related to defects in the crystal lattice."

Perhaps it is useful to think of the function (Bessel?) that when
convoluted with the lattice and molecular transform, would give rise to
this phenomenon.  It would be interesting to see if, on very long
exposure, a second concentric ring appeared further out from the spot.

Best-

Steve   

-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
Julian Nomme
Sent: Friday, October 29, 2010 2:10 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Strange spots

Google books: 
http://books.google.com/books?id=RqNb241Q484C&printsec=frontcover&dq=Mac
romolecular+Crystallography+with+Synchrotron+Radiation&hl=en&ei=JA3LTMe2
NMSnnQfAjN3mDw&sa=X&oi=book_result&ct=result&resnum=1&ved=0CC8Q6AEwAA#v=
onepage&q&f=false 


Julian

On 10/29/10 1:01 PM, Jrh wrote:
> Dear Gerard
> I will do a scan of fig 8.1b asap, probably Monday.
> Greetings,
> John
>
>
> Sent from my iPad
>
> On 29 Oct 2010, at 18:44, Gerard Bricogne
wrote:
>
>
>> Dear John,
>>
>>  Would it be possible to know more about what you are referring
to
>> without having to buy (or steal) your book :-)) ?
>>
>>  Thank you in advance!
>>
>>
>>  With best wishes,
>>
>>   Gerard.
>>
>> --
>> On Fri, Oct 29, 2010 at 06:41:51PM +0100, John R Helliwell wrote:
>>  
>>> Dear Dave,
>>> You have a collector's item there!
>>> The closest I have seen is illustrated in my book 'Macromolecular
>>> Crystallography with Synchrotron Radiation' page 321, which is a
small
>>> molecule example.
>>> Best wishes,
>>> John
>>> Prof John R Helliwell DSc
>>>
>>>
>>> On Fri, Oct 29, 2010 at 5:08 PM, David Goldstone
>>>   wrote:
>>>
 Dear All,

 Does anyone have any insight into what the circles around the spots
might
 be?

 cheers

 Dave
 --
 David Goldstone, PhD
 National Institute for Medical Research
 Molecular Structure
 The Ridgeway
 Mill Hill
 London NW7 1AA


  
>>>
>>>
>>> -- 
>>> Professor John R Helliwell DSc
>>>
>> -- 
>>
>>  ===
>>  * *
>>  * 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 *
>>  * *
>>  ===
>>  
>
Notice:  This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates Direct contact information
for affiliates is available at 
http://www.merck.com/contact/contacts.html) that may be confidential,
proprietary copyrighted and/or legally privileged. It is intended solely
for the use of the individual or entity named on this message. If you are
not the intended recipient, and have received this message in error,
please notify us immediately by reply e-mail and then delete it from 
your system.

Re: [ccp4bb] Strange spots

[Julian Nomme]

Google books: 
http://books.google.com/books?id=RqNb241Q484C&printsec=frontcover&dq=Macromolecular+Crystallography+with+Synchrotron+Radiation&hl=en&ei=JA3LTMe2NMSnnQfAjN3mDw&sa=X&oi=book_result&ct=result&resnum=1&ved=0CC8Q6AEwAA#v=onepage&q&f=false 



Julian

On 10/29/10 1:01 PM, Jrh wrote:

Dear Gerard
I will do a scan of fig 8.1b asap, probably Monday.
Greetings,
John


Sent from my iPad

On 29 Oct 2010, at 18:44, Gerard Bricogne  wrote:

   

Dear John,

 Would it be possible to know more about what you are referring to
without having to buy (or steal) your book :-)) ?

 Thank you in advance!


 With best wishes,

  Gerard.

--
On Fri, Oct 29, 2010 at 06:41:51PM +0100, John R Helliwell wrote:
 

Dear Dave,
You have a collector's item there!
The closest I have seen is illustrated in my book 'Macromolecular
Crystallography with Synchrotron Radiation' page 321, which is a small
molecule example.
Best wishes,
John
Prof John R Helliwell DSc


On Fri, Oct 29, 2010 at 5:08 PM, David Goldstone
  wrote:
   

Dear All,

Does anyone have any insight into what the circles around the spots might
be?

cheers

Dave
--
David Goldstone, PhD
National Institute for Medical Research
Molecular Structure
The Ridgeway
Mill Hill
London NW7 1AA


 



--
Professor John R Helliwell DSc
   

--

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

Re: [ccp4bb] Help with model bias in merihedral twin + Refmac5

[Peter Chan]

Dear Colin,

Thank you for the email. To be honest, I don't know exactly which map they are. 
From my understanding (and according to 
http://www.ccp4.ac.uk/schools/India-2010/tutorials/refmac/Murshudov30th.pdf), 
Refmac5 outputs 'normal map' 2mF(obs)-DF(calc) and 'difference map' 
2mF(obs)-DF(calc). I believe this is better than looking at the typical 
2F(obs)-F(calc), although there still appears to be a fair amount of model bias.

Best,
Peter


Subject: RE: [ccp4bb] Help with model bias in merihedral twin
Date: Wed, 27 Oct 2010 17:38:41 +0100
From: colin.n...@diamond.ac.uk
To: pc...@hotmail.com










Peter
Regarding the question
"Although the electron density map looks good, I am not 
sure if I should have too much confidence in it because I was not able to 
obtain 
'strong electron densities' from omitted sections of the model in a refinement. 
I don't know if this is an indicator for bias introduced somewhere. I would 
like 
to ask what may be some procedures I can try for checking and removing these 
biases"
 
Can you state 
what type of maps these are? 
 
The reason is 
the following. Taking PHENIX twinning maps as an example we have, in the manual 
- 
"By default, 
data is detwinned using algebraic techniques, unless the twin fraction is above 
45%, in which case detwinning is performed using proportionality of twin 
related 
Icalc values. Detwinning using the proportionality option, results in maps that 
are more biased towards the model, resulting in seemingly cleaner, but in the 
end less informative maps. The 2mFo-dFc map coefficients can be chosen to 
have sigmaA weighting (two_m_dtfo_d_fc) or not (two_dtfo_fc). IN both cases, 
the 
map coefficients correspond to the 'untwinned' data. A difference map can be 
constructed using either sigmaA weighted detwinned data (m_dtfo_d_fc), a sigmaA 
weighted gradient map (m_gradient) or a plain gradient map (gradient). The 
default is m_dtfo_d_fc but can be changed to gradient or m_gradient if desired. 
"
 
For the high 
twin fraction which you have (near 50%). my view is that 2Fo-Fc type maps are 
not optimal for this as they don't take account of the increased bias resulting 
from the extra degrees of freedom (i.e. splitting the intensity between the 
two reflections based on Icalc). For the reflections related by twinning higher 
order coefficients (e.g. 3Fo-2Fc or perhaps 4Fo-3Fc) would give noiser but less 
biased maps. 
 
Fibre 
diffraction folk do similar things when their Bessel function terms 
overlap.
 
Cheers
   
Colin
 

 


  
  
  From: CCP4 bulletin board 
  [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Peter Chan
Sent: 
  27 October 2010 02:00
To: CCP4BB@JISCMAIL.AC.UK
Subject: 
  [ccp4bb] Help with model bias in merihedral twin


  Hello All,

Not long ago I posted for some help with my 
  twinned dataset at 1.95 A, and have confirmed the twinning of P6(5) into 
  P6(5)22. Molecular replacement was successful and the twin refinement in 
  Refmac yieled R/Rfree of 21%/26%, with a twin fraction of 
  0.46.

Although the electron density map looks good, I am not sure if I 
  should have too much confidence in it because I was not able to obtain 
'strong 
  electron densities' from omitted sections of the model in a refinement. I 
  don't know if this is an indicator for bias introduced somewhere.

I 
  would like to ask what may be some procedures I can try for checking and 
  removing these biases, and a few additional related questions.

As 
  suggested to me previously, I have generated a total omit map with sfcheck in 
  ccp4i, using the refined pdb and unrefined data in P6(5). The .map file look 
a 
  little worse in quality (is this because of the twinning?) but is still 
  reasonable, with a few breaks in the main chain and side chains. 
  Interestingly, when I do a real space refinement against the total omit map, 
I 
  get slightly better Rfree at the earlier rounds of Refmac which diverges into 
  the numbers above. Why is this the case?

 Cycle   R 
  fact R free
   
  0   0.2301   
  0.2523
   1   
  0.2205   0.2534
   
  2   0.2164   
  0.2545
   3   
  0.2140   0.2554
   
  4   0.2123   0.2559   
  
   5   0.2117   
  0.2570
   6   
  0.2116   0.2575
   
  7   0.2112   
  0.2582
   8   
  0.2112   0.2584
   
  9   0.2109   0.2587
  
  10   0.2106   0.2597

Secondly, I read that I should 
  make sure the Free R flags should be consistent throughout the twin-related 
  indices. What may be the adverse outcome if this isn't enforced? Is Refmac 
  aware of this in a twin-refinement? If not, which tool could I use for 
  this?

I would very much appreciate any comments and 
  suggestions.

Best,
Peter Chan


 

--  

This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by retur

Re: [ccp4bb] Strange spots

[Jrh]

Dear Gerard
I will do a scan of fig 8.1b asap, probably Monday.
Greetings,
John


Sent from my iPad

On 29 Oct 2010, at 18:44, Gerard Bricogne  wrote:

> Dear John,
> 
> Would it be possible to know more about what you are referring to
> without having to buy (or steal) your book :-)) ?
> 
> Thank you in advance!
> 
> 
> With best wishes,
> 
>  Gerard.
> 
> --
> On Fri, Oct 29, 2010 at 06:41:51PM +0100, John R Helliwell wrote:
>> Dear Dave,
>> You have a collector's item there!
>> The closest I have seen is illustrated in my book 'Macromolecular
>> Crystallography with Synchrotron Radiation' page 321, which is a small
>> molecule example.
>> Best wishes,
>> John
>> Prof John R Helliwell DSc
>> 
>> 
>> On Fri, Oct 29, 2010 at 5:08 PM, David Goldstone
>>  wrote:
>>> Dear All,
>>> 
>>> Does anyone have any insight into what the circles around the spots might
>>> be?
>>> 
>>> cheers
>>> 
>>> Dave
>>> --
>>> David Goldstone, PhD
>>> National Institute for Medical Research
>>> Molecular Structure
>>> The Ridgeway
>>> Mill Hill
>>> London NW7 1AA
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Professor John R Helliwell DSc
> 
> -- 
> 
> ===
> * *
> * Gerard Bricogne g...@globalphasing.com  *
> * *
> * Global Phasing Ltd. *
> * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
> * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
> * *
> ===

Re: [ccp4bb] Strange spots

[Gerard Bricogne]

Dear John,

 Would it be possible to know more about what you are referring to
without having to buy (or steal) your book :-)) ?

 Thank you in advance!
 
 
 With best wishes,
 
  Gerard.

--
On Fri, Oct 29, 2010 at 06:41:51PM +0100, John R Helliwell wrote:
> Dear Dave,
> You have a collector's item there!
> The closest I have seen is illustrated in my book 'Macromolecular
> Crystallography with Synchrotron Radiation' page 321, which is a small
> molecule example.
> Best wishes,
> John
> Prof John R Helliwell DSc
> 
> 
> On Fri, Oct 29, 2010 at 5:08 PM, David Goldstone
>  wrote:
> > Dear All,
> >
> > Does anyone have any insight into what the circles around the spots might
> > be?
> >
> > cheers
> >
> > Dave
> > --
> > David Goldstone, PhD
> > National Institute for Medical Research
> > Molecular Structure
> > The Ridgeway
> > Mill Hill
> > London NW7 1AA
> >
> >
> 
> 
> 
> -- 
> Professor John R Helliwell DSc

-- 

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

Re: [ccp4bb] Strange spots

[John R Helliwell]

Dear Dave,
You have a collector's item there!
The closest I have seen is illustrated in my book 'Macromolecular
Crystallography with Synchrotron Radiation' page 321, which is a small
molecule example.
Best wishes,
John
Prof John R Helliwell DSc


On Fri, Oct 29, 2010 at 5:08 PM, David Goldstone
 wrote:
> Dear All,
>
> Does anyone have any insight into what the circles around the spots might
> be?
>
> cheers
>
> Dave
> --
> David Goldstone, PhD
> National Institute for Medical Research
> Molecular Structure
> The Ridgeway
> Mill Hill
> London NW7 1AA
>
>



-- 
Professor John R Helliwell DSc

Re: [ccp4bb] Bug in c_truncate?

[Peter Chan]

Dear All,

Thank you kindly for the replies and concerns over the problem I've 
experienced. I really appreciate them.

I do not know how often the I -> F conversion is done in CCP4i's F2MTZ GUI, 
especially with the FreeR flags preserved. Nevertheless, as mentioned, the 
problem seems to arise because [c]truncate does not recognize the FreeR column, 
unlike old-truncate. Whether this is a bug or new feature, it would be great if 
[c]truncate is (re-)programmed to recognize the FreeR column for a more 
streamlined import/I -> F conversion/uniqueify process executed in F2MTZ.

Also thanks for pointing out a relatively straight forward workaround using cad.

Best,
Peter
  

Re: [ccp4bb] Real space refinement [was: Against Method (R)]

[Pavel Afonine]

Hi Dirk,


yes, the apparently larger radius of convergence in real space refinement
> impresses me, too. Therefore, I usually do local real space refinement after
> manually correcting errors, either with Moloc at lower resolution or with
> Coot at higher resolution, prior to reciprocal space refinement.
>
> If I recall correctly, real space refinement was introduced by Robert
> Diamond in the 60s long before reciprocal space refinement. In the 90s
> Michael Chapman tried to revive it, but without much success, as far as I
> know. With the fast computers today, maybe the time has come again for real
> space refinement ...
>


you are absolutely right - it's time for real-space refinement:

 http://cci.lbl.gov/~afonine/rsr/rsr.pdf

and we don't have to do much and re-invent the wheel here since
R.Diamond, M.Chapman, T.Oldfield, R.Read, A.Jones and many others (see link
above) have created a great fundament, so all what one need to do now is to
mope up the best, re-think and implement using today's technology (again,
see above).

All the best!
Pavel.

Re: [ccp4bb] Against Method (R)

[Bart Hazes]

On 10-10-29 12:03 AM, Robbie Joosten wrote:

  Hi
Bart,
  
I agree with the building strategy you propose, but at some point it
stops helping and a bit more attention to detail is needed. Reciprocal
space refinement doesn't seem to do the fine details. It always
surprises me how much atoms still move when you real-space refine a
refined model, especially the waters. I admit this is not a fair
comparison.

Does the water move back to its old position if you follow up the
real-space refinement with more reciprocal refinement. If so, the map
may not have been a true representation of reality. Basically what I
was implying is that if the required model changes "details" are such
that they fall within the radius of convergence then the atoms should
move to their correct positions; unless something is keeping them from
moving such as an incorrectly placed side chain that causes a steric
conflict. Fix the incorrect side chain and your "details" will take
care of themselves. I don't imply that I can always spot an easy error
to fix and sometimes end up rebuilding several different ways in the
hopes that one will resolve whatever was the problem. If that doesn't
happen at some point you need to give up, especially if it does not
affect a functionally important region. I do think it is good practice
to point out regions in the model that are problematic and have never
had reviewers complain about that if it is clear you made the effort to
get it as good as possible given the data.
High resolution data helps, but better data makes it
tempting to put too little effort in optimising the model. I've seen
some horribly obvious errors in hi-res models (more than 10 sigma
difference density peaks for misplaced side chains). At the same time
there are quite a lot of low-res models that are exceptionally good.

Can't blame the data for that, in the end each person (and supervisor)
need to take responsibility for the models they produce and deposit.
Same applies to sequence data bases that are full of lazy errors. If
humans are involved both greatness and stupidy are likely outcomes.

Bart

Cheers,
Robbie
  
> Date: Thu, 28 Oct 2010 16:32:04 -0600
> From: bart.ha...@ualberta.ca
> Subject: Re: [ccp4bb] Against Method (R)
> To: CCP4BB@JISCMAIL.AC.UK
> 
> On 10-10-28 04:09 PM, Ethan Merritt wrote:
> > This I can answer based on experience. One can take the
coordinates from a structure
> > refined at near atomic resolution (~1.0A), including multiple
conformations,
> > partial occupancy waters, etc, and use it to calculate R
factors against a lower
> > resolution (say 2.5A) data set collected from an isomorphous
crystal. The
> > R factors from this total-rigid-body replacement will be
better than anything you
> > could get from refinement against the lower resolution data.
In fact, refinement
> > from this starting point will just make the R factors worse.
> >
> > What this tells us is that the crystallographic residuals can
recognize a
> > better model when they see one. But our refinement programs
are not good
> > enough to produce such a better model in the first place.
Worsr, they are not
> > even good enough to avoid degrading the model.
> >
> > That's essentially the same thing Bart said, perhaps a little
more pessimistic :-)
> >
> > cheers,
> >
> > Ethan
> > 
> 
> Not pessimistic at all, just realistic and perhaps even optimistic
for 
> methods developers as apparently there is still quite a bit of
progress 
> that can be made by improving the "search strategy" during
refinement.
> 
> During manual refinement I normally tell students not to bother
about 
> translating/rotating/torsioning atoms by just a tiny bit to make
it fit 
> better. Likewise there is no point in moving atoms a little bit to
  
> correct a distorted bond or bond length. If it needed to move that
  
> little bit the refinement program would have done it for you. Look
for 
> discreet errors in the problematic residue or its neighbors:
peptide 
> flips, 120 degree changes in side chain dihedrals, etc. If you can
find 
> and fix one of those errors a lot of the stereochemical
distortions and 
> non-ideal fit to density surrounding that residue will suddenly 
> disappear as well.
> 
> The benefit of high resolution is that it is much easier to pick
up and 
> fix such errors (or not make them in the first place)
> 
> Bart
> 
> -- 
> 
>

> 
> Bart Hazes (Associate Professor)
> Dept. of Medical Microbiology& Immunology
> University of Alberta
> 1-15 Medical Sciences Building
> Edmonton, Alberta
> Canada, T6G 2H7
> phone: 1-780-492-0042
> fax: 1-780-492-7521
> 
>



-- 



Bart Hazes (Associate Professor)
Dept. of Medical Microbiology & Immunology
University of Alberta
1-15 Medical Sciences Building
Edmonton, Alberta
Canada, T6G 2H

Re: [ccp4bb] Bug in c_truncate?

[Herman . Schreuder]

Dear Phil,

I think ctruncate is used as a general tool to convert I's to F's, so it
would be good to have an option to propagate FreeRflags. The workaround,
of course, is to use cad for this. I have the feeling (did not check)
that the problem of Peter arose because to ccp4i F2MTZ-SHELX gui was not
adapted to the new ctruncate, so that is something which has to be
repaired.

Best Herman

-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
Phil Evans
Sent: Friday, October 29, 2010 2:06 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Bug in c_truncate?

The normal use of [c]truncate is to take intensities from Scala, so it
wouldn't expect FreeR flags in the file.

I suppose this should be added for other uses of the program

Is this something that is often used? Do people import intensities into
CCP4 to convert them to Fs?

Phil


On 29 Oct 2010, at 13:01, herman.schreu...@sanofi-aventis.com wrote:

> Dear Peter,
> 
> Since I did not hear that your problem is solved here my two cents. I 
> did some tests using the ccp4i option "Convert Intensities to SFs" and

> found that here ctruncate completely ignored the FreeRflags. So my 
> conclusion is that ctruncate does not need FreeRflags and you can use 
> the following procedure:
> 
> 1) convert your hkl file (including FreeRflags) into an mtz with f2mtz

> without any special SHELX options. --> mtz 1
> Careful: a FreeRflag of 1 means an unfree reflection and the free 
> reflections have a FreeRflag of zero.
> 2) run ctruncate with the "Convert Intensities to SFs". You will loose
> your FreeRflags in this stage. --> mtz 2
> 3) add the FreeRflags from mtz 1 to mtz 2 using cad.
> 
> If you wish, I can give you a command file which will do this. It is a

> somewhat roundabout procedure and I hope that this bug (or feature) 
> will be fixed by the next release of ccp4.
> 
> Best,
> Herman
> 
> -Original Message-
> From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of 
> George M. Sheldrick
> Sent: Friday, October 29, 2010 12:30 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Bug in c_truncate?
> 
> Tim,
> 
> Although I always like to advocate XPREP, that would not work because 
> the .sca format - most unfortunately - does not know about free R
flags.
> 
> George
> 
> Prof. George M. Sheldrick FRS
> Dept. Structural Chemistry,
> University of Goettingen,
> Tammannstr. 4,
> D37077 Goettingen, Germany
> Tel. +49-551-39-3021 or -3068
> Fax. +49-551-39-22582
> 
> 
> On Fri, 29 Oct 2010, Tim Gruene wrote:
> 
>> Hello Peter,
>> 
>> the easiest way to overcome the problem might be to use xprep to 
>> export to sca-format and use scalepack2mtz for the conversion. That 
>> seems to be the least hasslesome way, although I am not totally sure 
>> that this procedure preserves the R-free flags set by xprep.
>> 
>> Tim
>> 
>> On Thu, Oct 28, 2010 at 12:48:14PM -0400, Peter Chan wrote:
>>> 
>>> Hello Tim,
>>> 
>>> Thank you for the suggestion. I have now tagged the working set as
> "1" and test set as "0". Unfortunately, it still gives the same error 
> about all Rfree being the same, and only in c-truncate but not 
> old-truncate. Perhaps I should install 6.1.3 and see if the problem 
> still persist.
>>> 
>>> Best,
>>> Peter
>>> 
 Date: Thu, 28 Oct 2010 16:29:31 +0200
 From: t...@shelx.uni-ac.gwdg.de
 Subject: Re: [ccp4bb] Bug in c_truncate?
 To: CCP4BB@JISCMAIL.AC.UK
 
 Hello Peter,
 
 I faintly rememeber a similar kind of problem, and think that if 
 you replace "-1" with "0", the problem should go away. It seemed 
 that "-1" is not an allowed flag for (some) ccp4 programs.
 
 Please let us know if this resolves the issue.
 
 Tim
 
 On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote:
> 
> 
> 
> 
> Dear Crystallographers,
> 
> Thank you all for the emails. Below are some details of the
> procedures I performed leading up to the problem.
> 
> The reflection file is my own data, processed in XDS and then
> flagging FreeR's in XPREP in thin resolution shells. I am using CCP4i 
> version 6.1.2. I tried looking for known/resolved issues/updates in 
> version 6.1.3 but could not find any so I assumed it is the same 
> version of f2mtz/ctruncate/uniqueify.
> 
> 
> I used the GUI version of F2MTZ, with the settings below:
> 
> - import file in SHELX format
> 
> - "keep existing FreeR flags"
> 
> - fortran format (3F4.0,2F8.3,F4.0)
> 
> - added data label "I other integer" // FreeRflag
> 
> The hkl file, in SHELX format, output by XPREP look something
> like this:
> 
> -26  -3   1  777.48   39.19
>  26  -3  -1  800.83   36.31
> -26   3  -1  782.67   37.97
>  27  -3   1  45.722  25.711  -1
> -27   3   1  -14.20   31.69  -1
> 
> Notice the test set is flagged "-1" and the working set is not
> flagged at all. This ac

Re: [ccp4bb] Against Method (R)

[Dirk Kostrewa]

Dear George,

thanks a lot! I see the point, that in reciprocal space refinement one 
could refine directly against the observed intensities and sigmas. But 
in principle, one could do iterative real space refinement, structure 
factor and intensity calculation for refinement statistics and weights, 
calculation of an improved electron density map (but that requires Fs 
again ...), and so forth until some convergence criterion is met. I 
wonder, which refinement scheme is more efficient.


The missing reflections in map calculation is something that we have to 
live with, and unless the data are severely incomplete, I must admit, 
that I don't worry too much.


The twinning problem is really severe! Here, I don't see how this could 
be done in a clever way in real space.


Interesting discussion ...

Best wishes,

Dirk.

Am 29.10.10 10:41, schrieb George M. Sheldrick:

Dear Dirk,

There are good reasons why real space refinement has never become popular.
With reciprocal space refinement, you refine directly against what you
measured, taking the standard uncertainly of each individual intensity
into account. In this context I was pleased to read in CCP4bb that REFMAC
will soon be refining against intensities (like SHELXL). Then the
assumptions made (e.g. no distortion of the expected intensity distribution
by e.g. NCS or twinning) and even 'bugs' in (c)truncate will no longer
matter. If for some reason a reflection wasn't measured, then simply
leaving it out it does not invalidate a recoprocal space refinement.
The same applies to reflections that are reserved for Rfree.

In contrast, the electron density is only theoretically correct if all
reflections between 0,0,0 and infinity are included in the Fourier
summation, For a twin it is even worse, because we don't know how to
partition the difference between Fo^2 and Fc^2 between the twin
components. None of the attempts to work around these problems are
entirely convincing. Maps and real space refinement are invaluable in
the intermediate stages of model building and correction, but the
final refinement should be performed in reciprocal space.

Best wishes, George

Prof. George M. Sheldrick FRS
Dept. Structural Chemistry,
University of Goettingen,
Tammannstr. 4,
D37077 Goettingen, Germany
Tel. +49-551-39-3021 or -3068
Fax. +49-551-39-22582


On Fri, 29 Oct 2010, Dirk Kostrewa wrote:


Hi Robbie,

yes, the apparently larger radius of convergence in real space refinement
impresses me, too. Therefore, I usually do local real space refinement after
manually correcting errors, either with Moloc at lower resolution or with Coot
at higher resolution, prior to reciprocal space refinement.

If I recall correctly, real space refinement was introduced by Robert Diamond
in the 60s long before reciprocal space refinement. In the 90s Michael Chapman
tried to revive it, but without much success, as far as I know. With the fast
computers today, maybe the time has come again for real space refinement ...

Best regards,

Dirk.

Am 29.10.10 08:03, schrieb Robbie Joosten:

Hi Bart,

I agree with the building strategy you propose, but at some point it stops
helping and a bit more attention to detail is needed. Reciprocal space
refinement doesn't seem to do the fine details. It always surprises me how
much atoms still move when you real-space refine a refined model, especially
the waters. I admit this is not a fair comparison.

High resolution data helps, but better data makes it tempting to put too
little effort in optimising the model. I've seen some horribly obvious
errors in hi-res models (more than 10 sigma difference density peaks for
misplaced side chains). At the same time there are quite a lot of low-res
models that are exceptionally good.

Cheers,
Robbie


Date: Thu, 28 Oct 2010 16:32:04 -0600
From: bart.ha...@ualberta.ca
Subject: Re: [ccp4bb] Against Method (R)
To: CCP4BB@JISCMAIL.AC.UK

On 10-10-28 04:09 PM, Ethan Merritt wrote:

This I can answer based on experience. One can take the coordinates

from a structure

refined at near atomic resolution (~1.0A), including multiple

conformations,

partial occupancy waters, etc, and use it to calculate R factors

against a lower

resolution (say 2.5A) data set collected from an isomorphous

crystal. The

R factors from this total-rigid-body replacement will be better

than anything you

could get from refinement against the lower resolution data. In

fact, refinement

from this starting point will just make the R factors worse.

What this tells us is that the crystallographic residuals can

recognize a

better model when they see one. But our refinement programs are not

good

enough to produce such a better model in the first place. Worsr,

they are not

even good enough to avoid degrading the model.

That's essentially the same thing Bart said, perhaps a little more

pessimistic :-)

cheers,

Ethan


Not pessimistic at all, just realistic and perhaps even optimistic for
methods developers as apparently there is still qu

Re: [ccp4bb] Bug in c_truncate?

[Robbie Joosten]

Hi Phil,

I do, but the freeR flag problem is easily circumvented. One can just use cad 
with the output mtz from ctruncate and the input mtz:

cad \
HKLIN2 $WORKDIR/raw.mtz \
HKLIN1 $WORKDIR/ctruncate.mtz \
HKLOUT $WORKDIR/ctruncate_withRfree.mtz \
<>$WORKDIR/mtz_creation.log
  LABIN FILE 2  E1=FREE
  LABIN FILE 1  ALLIN
  END
eof

Cheers,
Robbie




> Date: Fri, 29 Oct 2010 13:05:40 +0100
> From: p...@mrc-lmb.cam.ac.uk
> Subject: Re: [ccp4bb] Bug in c_truncate?
> To: CCP4BB@JISCMAIL.AC.UK
>
> The normal use of [c]truncate is to take intensities from Scala, so it 
> wouldn't expect FreeR flags in the file.
>
> I suppose this should be added for other uses of the program
>
> Is this something that is often used? Do people import intensities into CCP4 
> to convert them to Fs?
>
> Phil
>
>
> On 29 Oct 2010, at 13:01, herman.schreu...@sanofi-aventis.com wrote:
>
> > Dear Peter,
> >
> > Since I did not hear that your problem is solved here my two cents. I
> > did some tests using the ccp4i option "Convert Intensities to SFs" and
> > found that here ctruncate completely ignored the FreeRflags. So my
> > conclusion is that ctruncate does not need FreeRflags and you can use
> > the following procedure:
> >
> > 1) convert your hkl file (including FreeRflags) into an mtz with f2mtz
> > without any special SHELX options. --> mtz 1
> > Careful: a FreeRflag of 1 means an unfree reflection and the free
> > reflections have a FreeRflag of zero.
> > 2) run ctruncate with the "Convert Intensities to SFs". You will loose
> > your FreeRflags in this stage. --> mtz 2
> > 3) add the FreeRflags from mtz 1 to mtz 2 using cad.
> >
> > If you wish, I can give you a command file which will do this. It is a
> > somewhat roundabout procedure and I hope that this bug (or feature) will
> > be fixed by the next release of ccp4.
> >
> > Best,
> > Herman
> >
> > -Original Message-
> > From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
> > George M. Sheldrick
> > Sent: Friday, October 29, 2010 12:30 PM
> > To: CCP4BB@JISCMAIL.AC.UK
> > Subject: Re: [ccp4bb] Bug in c_truncate?
> >
> > Tim,
> >
> > Although I always like to advocate XPREP, that would not work because
> > the .sca format - most unfortunately - does not know about free R flags.
> >
> > George
> >
> > Prof. George M. Sheldrick FRS
> > Dept. Structural Chemistry,
> > University of Goettingen,
> > Tammannstr. 4,
> > D37077 Goettingen, Germany
> > Tel. +49-551-39-3021 or -3068
> > Fax. +49-551-39-22582
> >
> >
> > On Fri, 29 Oct 2010, Tim Gruene wrote:
> >
> >> Hello Peter,
> >>
> >> the easiest way to overcome the problem might be to use xprep to
> >> export to sca-format and use scalepack2mtz for the conversion. That
> >> seems to be the least hasslesome way, although I am not totally sure
> >> that this procedure preserves the R-free flags set by xprep.
> >>
> >> Tim
> >>
> >> On Thu, Oct 28, 2010 at 12:48:14PM -0400, Peter Chan wrote:
> >>>
> >>> Hello Tim,
> >>>
> >>> Thank you for the suggestion. I have now tagged the working set as
> > "1" and test set as "0". Unfortunately, it still gives the same error
> > about all Rfree being the same, and only in c-truncate but not
> > old-truncate. Perhaps I should install 6.1.3 and see if the problem
> > still persist.
> >>>
> >>> Best,
> >>> Peter
> >>>
>  Date: Thu, 28 Oct 2010 16:29:31 +0200
>  From: t...@shelx.uni-ac.gwdg.de
>  Subject: Re: [ccp4bb] Bug in c_truncate?
>  To: CCP4BB@JISCMAIL.AC.UK
> 
>  Hello Peter,
> 
>  I faintly rememeber a similar kind of problem, and think that if
>  you replace "-1" with "0", the problem should go away. It seemed
>  that "-1" is not an allowed flag for (some) ccp4 programs.
> 
>  Please let us know if this resolves the issue.
> 
>  Tim
> 
>  On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote:
> >
> >
> >
> >
> > Dear Crystallographers,
> >
> > Thank you all for the emails. Below are some details of the
> > procedures I performed leading up to the problem.
> >
> > The reflection file is my own data, processed in XDS and then
> > flagging FreeR's in XPREP in thin resolution shells. I am using CCP4i
> > version 6.1.2. I tried looking for known/resolved issues/updates in
> > version 6.1.3 but could not find any so I assumed it is the same version
> > of f2mtz/ctruncate/uniqueify.
> >
> >
> > I used the GUI version of F2MTZ, with the settings below:
> >
> > - import file in SHELX format
> >
> > - "keep existing FreeR flags"
> >
> > - fortran format (3F4.0,2F8.3,F4.0)
> >
> > - added data label "I other integer" // FreeRflag
> >
> > The hkl file, in SHELX format, output by XPREP look something
> > like this:
> >
> > -26 -3 1 777.48 39.19
> > 26 -3 -1 800.83 36.31
> > -26 3 -1 782.67 37.97
> > 27 -3 1 45.722 25.711 -1
> > -27 3 1 -14.20 3

Re: [ccp4bb] Bug in c_truncate?

[Phil Evans]

The normal use of [c]truncate is to take intensities from Scala, so it wouldn't 
expect FreeR flags in the file.

I suppose this should be added for other uses of the program

Is this something that is often used? Do people import intensities into CCP4 to 
convert them to Fs?

Phil


On 29 Oct 2010, at 13:01, herman.schreu...@sanofi-aventis.com wrote:

> Dear Peter,
> 
> Since I did not hear that your problem is solved here my two cents. I
> did some tests using the ccp4i option "Convert Intensities to SFs" and
> found that here ctruncate completely ignored the FreeRflags. So my
> conclusion is that ctruncate does not need FreeRflags and you can use
> the following procedure:
> 
> 1) convert your hkl file (including FreeRflags) into an mtz with f2mtz
> without any special SHELX options. --> mtz 1
> Careful: a FreeRflag of 1 means an unfree reflection and the free
> reflections have a FreeRflag of zero.  
> 2) run ctruncate with the "Convert Intensities to SFs". You will loose
> your FreeRflags in this stage. --> mtz 2
> 3) add the FreeRflags from mtz 1 to mtz 2 using cad.
> 
> If you wish, I can give you a command file which will do this. It is a
> somewhat roundabout procedure and I hope that this bug (or feature) will
> be fixed by the next release of ccp4.
> 
> Best,
> Herman
> 
> -Original Message-
> From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
> George M. Sheldrick
> Sent: Friday, October 29, 2010 12:30 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Bug in c_truncate?
> 
> Tim,
> 
> Although I always like to advocate XPREP, that would not work because
> the .sca format - most unfortunately - does not know about free R flags.
> 
> George
> 
> Prof. George M. Sheldrick FRS
> Dept. Structural Chemistry,
> University of Goettingen,
> Tammannstr. 4,
> D37077 Goettingen, Germany
> Tel. +49-551-39-3021 or -3068
> Fax. +49-551-39-22582
> 
> 
> On Fri, 29 Oct 2010, Tim Gruene wrote:
> 
>> Hello Peter,
>> 
>> the easiest way to overcome the problem might be to use xprep to 
>> export to sca-format and use scalepack2mtz for the conversion. That 
>> seems to be the least hasslesome way, although I am not totally sure 
>> that this procedure preserves the R-free flags set by xprep.
>> 
>> Tim
>> 
>> On Thu, Oct 28, 2010 at 12:48:14PM -0400, Peter Chan wrote:
>>> 
>>> Hello Tim,
>>> 
>>> Thank you for the suggestion. I have now tagged the working set as
> "1" and test set as "0". Unfortunately, it still gives the same error
> about all Rfree being the same, and only in c-truncate but not
> old-truncate. Perhaps I should install 6.1.3 and see if the problem
> still persist.
>>> 
>>> Best,
>>> Peter
>>> 
 Date: Thu, 28 Oct 2010 16:29:31 +0200
 From: t...@shelx.uni-ac.gwdg.de
 Subject: Re: [ccp4bb] Bug in c_truncate?
 To: CCP4BB@JISCMAIL.AC.UK
 
 Hello Peter,
 
 I faintly rememeber a similar kind of problem, and think that if 
 you replace "-1" with "0", the problem should go away. It seemed 
 that "-1" is not an allowed flag for (some) ccp4 programs.
 
 Please let us know if this resolves the issue.
 
 Tim
 
 On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote:
> 
> 
> 
> 
> Dear Crystallographers,
> 
> Thank you all for the emails. Below are some details of the
> procedures I performed leading up to the problem.
> 
> The reflection file is my own data, processed in XDS and then
> flagging FreeR's in XPREP in thin resolution shells. I am using CCP4i
> version 6.1.2. I tried looking for known/resolved issues/updates in
> version 6.1.3 but could not find any so I assumed it is the same version
> of f2mtz/ctruncate/uniqueify.
> 
> 
> I used the GUI version of F2MTZ, with the settings below:
> 
> - import file in SHELX format
> 
> - "keep existing FreeR flags"
> 
> - fortran format (3F4.0,2F8.3,F4.0)
> 
> - added data label "I other integer" // FreeRflag
> 
> The hkl file, in SHELX format, output by XPREP look something
> like this:
> 
> -26  -3   1  777.48   39.19
>  26  -3  -1  800.83   36.31
> -26   3  -1  782.67   37.97
>  27  -3   1  45.722  25.711  -1
> -27   3   1  -14.20   31.69  -1
> 
> Notice the test set is flagged "-1" and the working set is not
> flagged at all. This actually lead to another error message in f2mtz
> about missing FreeR flags. From my understanding, the SHELX flagging
> convention is "1" for working and "-1" for test. So I manually tagged
> the working set with "1" using vi:
> 
> -26  -3   1  777.48   39.19   1
>  26  -3  -1  800.83   36.31   1
> -26   3  -1  782.67   37.97   1
>  27  -3   1  45.722  25.711  -1
> -27   3   1  -14.20   31.69  -1
> 
> This is the file which gives me the error message: "Problem with
> FREE column in input file. All flags apparently identical. Check input
> file.". Apparently, import to mtz works ok 

Re: [ccp4bb] Bug in c_truncate?

[Herman . Schreuder]

Dear Peter,

Since I did not hear that your problem is solved here my two cents. I
did some tests using the ccp4i option "Convert Intensities to SFs" and
found that here ctruncate completely ignored the FreeRflags. So my
conclusion is that ctruncate does not need FreeRflags and you can use
the following procedure:

1) convert your hkl file (including FreeRflags) into an mtz with f2mtz
without any special SHELX options. --> mtz 1
Careful: a FreeRflag of 1 means an unfree reflection and the free
reflections have a FreeRflag of zero.  
2) run ctruncate with the "Convert Intensities to SFs". You will loose
your FreeRflags in this stage. --> mtz 2
3) add the FreeRflags from mtz 1 to mtz 2 using cad.

If you wish, I can give you a command file which will do this. It is a
somewhat roundabout procedure and I hope that this bug (or feature) will
be fixed by the next release of ccp4.

Best,
Herman

-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
George M. Sheldrick
Sent: Friday, October 29, 2010 12:30 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Bug in c_truncate?

Tim,

Although I always like to advocate XPREP, that would not work because
the .sca format - most unfortunately - does not know about free R flags.

George

Prof. George M. Sheldrick FRS
Dept. Structural Chemistry,
University of Goettingen,
Tammannstr. 4,
D37077 Goettingen, Germany
Tel. +49-551-39-3021 or -3068
Fax. +49-551-39-22582


On Fri, 29 Oct 2010, Tim Gruene wrote:

> Hello Peter,
> 
> the easiest way to overcome the problem might be to use xprep to 
> export to sca-format and use scalepack2mtz for the conversion. That 
> seems to be the least hasslesome way, although I am not totally sure 
> that this procedure preserves the R-free flags set by xprep.
> 
> Tim
> 
> On Thu, Oct 28, 2010 at 12:48:14PM -0400, Peter Chan wrote:
> > 
> > Hello Tim,
> > 
> > Thank you for the suggestion. I have now tagged the working set as
"1" and test set as "0". Unfortunately, it still gives the same error
about all Rfree being the same, and only in c-truncate but not
old-truncate. Perhaps I should install 6.1.3 and see if the problem
still persist.
> > 
> > Best,
> > Peter
> > 
> > > Date: Thu, 28 Oct 2010 16:29:31 +0200
> > > From: t...@shelx.uni-ac.gwdg.de
> > > Subject: Re: [ccp4bb] Bug in c_truncate?
> > > To: CCP4BB@JISCMAIL.AC.UK
> > > 
> > > Hello Peter,
> > > 
> > > I faintly rememeber a similar kind of problem, and think that if 
> > > you replace "-1" with "0", the problem should go away. It seemed 
> > > that "-1" is not an allowed flag for (some) ccp4 programs.
> > > 
> > > Please let us know if this resolves the issue.
> > > 
> > > Tim
> > > 
> > > On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Dear Crystallographers,
> > > > 
> > > > Thank you all for the emails. Below are some details of the
procedures I performed leading up to the problem.
> > > > 
> > > > The reflection file is my own data, processed in XDS and then
flagging FreeR's in XPREP in thin resolution shells. I am using CCP4i
version 6.1.2. I tried looking for known/resolved issues/updates in
version 6.1.3 but could not find any so I assumed it is the same version
of f2mtz/ctruncate/uniqueify.
> > > > 
> > > > 
> > > > I used the GUI version of F2MTZ, with the settings below:
> > > > 
> > > > - import file in SHELX format
> > > > 
> > > > - "keep existing FreeR flags"
> > > > 
> > > > - fortran format (3F4.0,2F8.3,F4.0)
> > > > 
> > > > - added data label "I other integer" // FreeRflag
> > > > 
> > > > The hkl file, in SHELX format, output by XPREP look something
like this:
> > > > 
> > > >  -26  -3   1  777.48   39.19
> > > >   26  -3  -1  800.83   36.31
> > > >  -26   3  -1  782.67   37.97
> > > >   27  -3   1  45.722  25.711  -1
> > > >  -27   3   1  -14.20   31.69  -1
> > > > 
> > > > Notice the test set is flagged "-1" and the working set is not
flagged at all. This actually lead to another error message in f2mtz
about missing FreeR flags. From my understanding, the SHELX flagging
convention is "1" for working and "-1" for test. So I manually tagged
the working set with "1" using vi:
> > > > 
> > > >  -26  -3   1  777.48   39.19   1
> > > >   26  -3  -1  800.83   36.31   1
> > > >  -26   3  -1  782.67   37.97   1
> > > >   27  -3   1  45.722  25.711  -1
> > > >  -27   3   1  -14.20   31.69  -1
> > > > 
> > > > This is the file which gives me the error message: "Problem with
FREE column in input file. All flags apparently identical. Check input
file.". Apparently, import to mtz works ok when I use old-truncate
instead of c-truncate.
> > > > 
> > > > Best,
> > > > Peter
> > > >   
> > > --
> > > --
> > > Tim Gruene
> > > Institut fuer anorganische Chemie
> > > Tammannstr. 4
> > > D-37077 Goettingen
> > > 
> > > phone: +49 (0)551 39 22149
> > > 
> > > GPG Key ID = A46BEE1A
> > > 
> >   
> --
> --
>

Re: [ccp4bb] Bug in c_truncate?

[George M. Sheldrick]

Tim,

Although I always like to advocate XPREP, that would not work because the 
.sca format - most unfortunately - does not know about free R flags.

George

Prof. George M. Sheldrick FRS
Dept. Structural Chemistry,
University of Goettingen,
Tammannstr. 4,
D37077 Goettingen, Germany
Tel. +49-551-39-3021 or -3068
Fax. +49-551-39-22582


On Fri, 29 Oct 2010, Tim Gruene wrote:

> Hello Peter,
> 
> the easiest way to overcome the problem might be to use xprep to export to
> sca-format and use scalepack2mtz for the conversion. That seems to be the 
> least
> hasslesome way, although I am not totally sure that this procedure preserves 
> the
> R-free flags set by xprep.
> 
> Tim
> 
> On Thu, Oct 28, 2010 at 12:48:14PM -0400, Peter Chan wrote:
> > 
> > Hello Tim,
> > 
> > Thank you for the suggestion. I have now tagged the working set as "1" and 
> > test set as "0". Unfortunately, it still gives the same error about all 
> > Rfree being the same, and only in c-truncate but not old-truncate. Perhaps 
> > I should install 6.1.3 and see if the problem still persist.
> > 
> > Best,
> > Peter
> > 
> > > Date: Thu, 28 Oct 2010 16:29:31 +0200
> > > From: t...@shelx.uni-ac.gwdg.de
> > > Subject: Re: [ccp4bb] Bug in c_truncate?
> > > To: CCP4BB@JISCMAIL.AC.UK
> > > 
> > > Hello Peter,
> > > 
> > > I faintly rememeber a similar kind of problem, and think that if you 
> > > replace
> > > "-1" with "0", the problem should go away. It seemed that "-1" is not an 
> > > allowed
> > > flag for (some) ccp4 programs.
> > > 
> > > Please let us know if this resolves the issue.
> > > 
> > > Tim
> > > 
> > > On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Dear Crystallographers,
> > > > 
> > > > Thank you all for the emails. Below are some details of the procedures 
> > > > I performed leading up to the problem.
> > > > 
> > > > The reflection file is my own data, processed in XDS and then flagging 
> > > > FreeR's in XPREP in thin resolution shells. I am using CCP4i version 
> > > > 6.1.2. I tried looking for known/resolved issues/updates in version 
> > > > 6.1.3 but could not find any so I assumed it is the same version of 
> > > > f2mtz/ctruncate/uniqueify.
> > > > 
> > > > 
> > > > I used the GUI version of F2MTZ, with the settings below:
> > > > 
> > > > - import file in SHELX format
> > > > 
> > > > - "keep existing FreeR flags"
> > > > 
> > > > - fortran format (3F4.0,2F8.3,F4.0)
> > > > 
> > > > - added data label "I other integer" // FreeRflag
> > > > 
> > > > The hkl file, in SHELX format, output by XPREP look something like this:
> > > > 
> > > >  -26  -3   1  777.48   39.19
> > > >   26  -3  -1  800.83   36.31
> > > >  -26   3  -1  782.67   37.97
> > > >   27  -3   1  45.722  25.711  -1
> > > >  -27   3   1  -14.20   31.69  -1
> > > > 
> > > > Notice the test set is flagged "-1" and the working set is not flagged 
> > > > at all. This actually lead to another error message in f2mtz about 
> > > > missing FreeR flags. From my understanding, the SHELX flagging 
> > > > convention is "1" for working and "-1" for test. So I manually tagged 
> > > > the working set with "1" using vi:
> > > > 
> > > >  -26  -3   1  777.48   39.19   1
> > > >   26  -3  -1  800.83   36.31   1
> > > >  -26   3  -1  782.67   37.97   1
> > > >   27  -3   1  45.722  25.711  -1
> > > >  -27   3   1  -14.20   31.69  -1
> > > > 
> > > > This is the file which gives me the error message: "Problem with FREE 
> > > > column in input file. All flags apparently identical. Check input 
> > > > file.". Apparently, import to mtz works ok when I use old-truncate 
> > > > instead of c-truncate.
> > > > 
> > > > Best,
> > > > Peter
> > > >   
> > > -- 
> > > --
> > > Tim Gruene
> > > Institut fuer anorganische Chemie
> > > Tammannstr. 4
> > > D-37077 Goettingen
> > > 
> > > phone: +49 (0)551 39 22149
> > > 
> > > GPG Key ID = A46BEE1A
> > > 
> >   
> -- 
> --
> Tim Gruene
> Institut fuer anorganische Chemie
> Tammannstr. 4
> D-37077 Goettingen
> 
> phone: +49 (0)551 39 22149
> 
> GPG Key ID = A46BEE1A
> 
> 

[ccp4bb] Position as Postdoctoral Research Fellow - in membrane proteins structural biology , Oslo Norway

[Preben Morth]

Dear CCP4 

I have an open postion for biochemist/structural biologist with interest  in  
membrane proteins. 
I  would be most grateful if you could forward this email  to any suitable 
candidates you may know of

Best regards,
Preben

Postdoctoral Research Fellow -

(Membrane Proteins Structural Biology)

Position as Postdoctoral Research Fellow - in membrane proteins structural 
biology

Ref.no.: 2010/ 8649

Available at the Centre for Molecular Medicine Norway (NCMM), Nordic EMBL 
Partnership, University of Oslo.

 

A post-doctoral position for an initial two years with possibility of extension 
is available in the laboratory of Dr. Preben Morth. The Postdoctoral position 
is funded by an NCMM grant and is available from the 1st of January 2011. The 
Focus of the research will include membrane protein involved with 
osmoregualtion and anion transport in bacteria and higher eukaryotes. Projects 
focus on bicarbonate transport through the plasma membrane and the intra 
cellular complexes involved with their tight control.

 

NCMM, was established in 2007 as a partner institution of the European 
Molecular Biology Laboratory (www.embl.org). NCMM is located in brand new 
laboratories in the University of Oslo and National Hospital Biomedical Campus 
in the Oslo Research Park and Preclinical Medicine buildings. A new Structural 
Biology laboratory at NCMM, headed by Dr. J. Preben Morth has been established, 
with focus in membrane proteins. This new laboratory is well equipped for a 
modern approach to structural biology, it include recombinant expression in 
bacterial and eukaryotic systems, new protein purification equipment and 
incubators . There is excellent synchrotron access to ESRF through the 
Norwegian bag proposal.

The University of Oslo has an in-house mass spectroscopy department for fast 
protein identification, facilities for electrophysiology and visualization 
equipment with electron microscopy and confocal microscopy.
 
Applicants must have a PhD, and should have extensive experience with vector 
design and cloning in E. coli and baculovirus or yeast expression systems, 
protein purification and characterization.  Experience with membrane proteins 
and protein crystallography will be an advantage but not necessary. A good 
command of English is required.

Oslo is a vibrant city in the south of Norway, with ready access to skiing in 
the winter and hiking in the summer. The Oslo bay and most of the coastline 
offer excellent scuba diving opportunities.  

For more information, please see the NCMM home page: http://www.ncmm.uio.no

Please also refer to the regulations pertaining to the conditions of employment 
for post-doctoral fellowship positions:

http://www.uio.no/admhb/reglhb/personal/tilsettingvitenskapelig/regulationstermcondition.xml

Salary:

Postdoctoral Research Fellow (SKO, 1352), pay grade: 57 – 64 (NOK 448 200– 510 
000 depending on experience and qualifications)

The application must include:

Application letter including a statement of interest, summarizing the 
applicant's scientific work and interests and describing how she/he fits the 
description of the person we seek
CV (summarizing education, positions, pedagogical experience, administrative 
experience and other qualifying activity), including a list of published and 
unpublished works
Copies of educational certificates, transcript of records, letters of 
recommendation
A complete list of publications and up to 5 academic works that the applicant 
wishes to be considered by the evaluation committee
Names and contact details of 2-3 references (name, relation to candidate, 
e-mail and telephone number)
Extended Applicant Form, to be filled in by the applicant
http://www.uio.no/om/jobb-ved-uio/ledige-stillinger/2010/vitenskapelige/sokerskjema_GBR.rtf

Closing date for applications:  15. November, 2010

The application should be sent electronically as a single pdf-file to 
recruitm...@ncmm.uio.no labelled with Ref.no.: 2010/8649

The University of Oslo has an agreement for all employees, aiming to secure 
rights to research results a.o. The University of Oslo has a goal of recruiting 
more women in academic positions. Women are encouraged to apply. In accordance 
with the University of Oslo’s equal opportunities policy, we invite 
applications from all interested individuals regardless of gender or ethnicity.

Contacts:

Requests for application information should be directed to CAO Elin Kaurstad 
E-mail: e.k.kaurs...@ncmm.uio.no

Requests for further information and inquiries regarding the post can be 
directed to Group Leader J.Preben Morth, PhD. E-mail: j.p.mo...@ncmm.uio.no
Please see the following URL for further details and guidelines for appointment 
to research fellowships at the University of Oslo:
http://www.matnat.uio.no/internt/administrasjonen/personal/Forskrifter-phd-postdoc-eng.pdf
The University of Oslo (UiO) wishes to achieve a more equal gender distribution 
of scientific staff. Female candidates are 

Re: [ccp4bb] Bug in c_truncate?

[Tim Gruene]

Hello Peter,

the easiest way to overcome the problem might be to use xprep to export to
sca-format and use scalepack2mtz for the conversion. That seems to be the least
hasslesome way, although I am not totally sure that this procedure preserves the
R-free flags set by xprep.

Tim

On Thu, Oct 28, 2010 at 12:48:14PM -0400, Peter Chan wrote:
> 
> Hello Tim,
> 
> Thank you for the suggestion. I have now tagged the working set as "1" and 
> test set as "0". Unfortunately, it still gives the same error about all Rfree 
> being the same, and only in c-truncate but not old-truncate. Perhaps I should 
> install 6.1.3 and see if the problem still persist.
> 
> Best,
> Peter
> 
> > Date: Thu, 28 Oct 2010 16:29:31 +0200
> > From: t...@shelx.uni-ac.gwdg.de
> > Subject: Re: [ccp4bb] Bug in c_truncate?
> > To: CCP4BB@JISCMAIL.AC.UK
> > 
> > Hello Peter,
> > 
> > I faintly rememeber a similar kind of problem, and think that if you replace
> > "-1" with "0", the problem should go away. It seemed that "-1" is not an 
> > allowed
> > flag for (some) ccp4 programs.
> > 
> > Please let us know if this resolves the issue.
> > 
> > Tim
> > 
> > On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote:
> > > 
> > > 
> > > 
> > > 
> > > Dear Crystallographers,
> > > 
> > > Thank you all for the emails. Below are some details of the procedures I 
> > > performed leading up to the problem.
> > > 
> > > The reflection file is my own data, processed in XDS and then flagging 
> > > FreeR's in XPREP in thin resolution shells. I am using CCP4i version 
> > > 6.1.2. I tried looking for known/resolved issues/updates in version 6.1.3 
> > > but could not find any so I assumed it is the same version of 
> > > f2mtz/ctruncate/uniqueify.
> > > 
> > > 
> > > I used the GUI version of F2MTZ, with the settings below:
> > > 
> > > - import file in SHELX format
> > > 
> > > - "keep existing FreeR flags"
> > > 
> > > - fortran format (3F4.0,2F8.3,F4.0)
> > > 
> > > - added data label "I other integer" // FreeRflag
> > > 
> > > The hkl file, in SHELX format, output by XPREP look something like this:
> > > 
> > >  -26  -3   1  777.48   39.19
> > >   26  -3  -1  800.83   36.31
> > >  -26   3  -1  782.67   37.97
> > >   27  -3   1  45.722  25.711  -1
> > >  -27   3   1  -14.20   31.69  -1
> > > 
> > > Notice the test set is flagged "-1" and the working set is not flagged at 
> > > all. This actually lead to another error message in f2mtz about missing 
> > > FreeR flags. From my understanding, the SHELX flagging convention is "1" 
> > > for working and "-1" for test. So I manually tagged the working set with 
> > > "1" using vi:
> > > 
> > >  -26  -3   1  777.48   39.19   1
> > >   26  -3  -1  800.83   36.31   1
> > >  -26   3  -1  782.67   37.97   1
> > >   27  -3   1  45.722  25.711  -1
> > >  -27   3   1  -14.20   31.69  -1
> > > 
> > > This is the file which gives me the error message: "Problem with FREE 
> > > column in input file. All flags apparently identical. Check input file.". 
> > > Apparently, import to mtz works ok when I use old-truncate instead of 
> > > c-truncate.
> > > 
> > > Best,
> > > Peter
> > > 
> > -- 
> > --
> > Tim Gruene
> > Institut fuer anorganische Chemie
> > Tammannstr. 4
> > D-37077 Goettingen
> > 
> > phone: +49 (0)551 39 22149
> > 
> > GPG Key ID = A46BEE1A
> > 
> 
-- 
--
Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen

phone: +49 (0)551 39 22149

GPG Key ID = A46BEE1A



signature.asc
Description: Digital signature

Re: [ccp4bb] Against Method (R)

[George M. Sheldrick]

Dear Dirk,

There are good reasons why real space refinement has never become popular. 
With reciprocal space refinement, you refine directly against what you 
measured, taking the standard uncertainly of each individual intensity
into account. In this context I was pleased to read in CCP4bb that REFMAC
will soon be refining against intensities (like SHELXL). Then the 
assumptions made (e.g. no distortion of the expected intensity distribution 
by e.g. NCS or twinning) and even 'bugs' in (c)truncate will no longer 
matter. If for some reason a reflection wasn't measured, then simply 
leaving it out it does not invalidate a recoprocal space refinement. 
The same applies to reflections that are reserved for Rfree.

In contrast, the electron density is only theoretically correct if all 
reflections between 0,0,0 and infinity are included in the Fourier 
summation, For a twin it is even worse, because we don't know how to 
partition the difference between Fo^2 and Fc^2 between the twin 
components. None of the attempts to work around these problems are 
entirely convincing. Maps and real space refinement are invaluable in 
the intermediate stages of model building and correction, but the 
final refinement should be performed in reciprocal space.

Best wishes, George  

Prof. George M. Sheldrick FRS
Dept. Structural Chemistry,
University of Goettingen,
Tammannstr. 4,
D37077 Goettingen, Germany
Tel. +49-551-39-3021 or -3068
Fax. +49-551-39-22582


On Fri, 29 Oct 2010, Dirk Kostrewa wrote:

> Hi Robbie,
> 
> yes, the apparently larger radius of convergence in real space refinement
> impresses me, too. Therefore, I usually do local real space refinement after
> manually correcting errors, either with Moloc at lower resolution or with Coot
> at higher resolution, prior to reciprocal space refinement.
> 
> If I recall correctly, real space refinement was introduced by Robert Diamond
> in the 60s long before reciprocal space refinement. In the 90s Michael Chapman
> tried to revive it, but without much success, as far as I know. With the fast
> computers today, maybe the time has come again for real space refinement ...
> 
> Best regards,
> 
> Dirk.
> 
> Am 29.10.10 08:03, schrieb Robbie Joosten:
> > Hi Bart,
> >
> > I agree with the building strategy you propose, but at some point it stops
> > helping and a bit more attention to detail is needed. Reciprocal space
> > refinement doesn't seem to do the fine details. It always surprises me how
> > much atoms still move when you real-space refine a refined model, especially
> > the waters. I admit this is not a fair comparison.
> >
> > High resolution data helps, but better data makes it tempting to put too
> > little effort in optimising the model. I've seen some horribly obvious
> > errors in hi-res models (more than 10 sigma difference density peaks for
> > misplaced side chains). At the same time there are quite a lot of low-res
> > models that are exceptionally good.
> >
> > Cheers,
> > Robbie
> >
> > > Date: Thu, 28 Oct 2010 16:32:04 -0600
> > > From: bart.ha...@ualberta.ca
> > > Subject: Re: [ccp4bb] Against Method (R)
> > > To: CCP4BB@JISCMAIL.AC.UK
> > >
> > > On 10-10-28 04:09 PM, Ethan Merritt wrote:
> > > > This I can answer based on experience. One can take the coordinates 
> > from a structure
> > > > refined at near atomic resolution (~1.0A), including multiple 
> > conformations,
> > > > partial occupancy waters, etc, and use it to calculate R factors 
> > against a lower
> > > > resolution (say 2.5A) data set collected from an isomorphous 
> > crystal. The
> > > > R factors from this total-rigid-body replacement will be better 
> > than anything you
> > > > could get from refinement against the lower resolution data. In 
> > fact, refinement
> > > > from this starting point will just make the R factors worse.
> > > >
> > > > What this tells us is that the crystallographic residuals can 
> > recognize a
> > > > better model when they see one. But our refinement programs are not 
> > good
> > > > enough to produce such a better model in the first place. Worsr, 
> > they are not
> > > > even good enough to avoid degrading the model.
> > > >
> > > > That's essentially the same thing Bart said, perhaps a little more 
> > pessimistic :-)
> > > >
> > > > cheers,
> > > >
> > > > Ethan
> > > >
> > >
> > > Not pessimistic at all, just realistic and perhaps even optimistic for
> > > methods developers as apparently there is still quite a bit of progress
> > > that can be made by improving the "search strategy" during refinement.
> > >
> > > During manual refinement I normally tell students not to bother about
> > > translating/rotating/torsioning atoms by just a tiny bit to make it fit
> > > better. Likewise there is no point in moving atoms a little bit to
> > > correct a distorted bond or bond length. If it needed to move that
> > > little bit the refinement program would have done it for you. Look for
> > > discreet errors in the problematic residue or its neig

Re: [ccp4bb] Against Method (R)

[Dirk Kostrewa]

Hi Robbie,

yes, the apparently larger radius of convergence in real space 
refinement impresses me, too. Therefore, I usually do local real space 
refinement after manually correcting errors, either with Moloc at lower 
resolution or with Coot at higher resolution, prior to reciprocal space 
refinement.


If I recall correctly, real space refinement was introduced by Robert 
Diamond in the 60s long before reciprocal space refinement. In the 90s 
Michael Chapman tried to revive it, but without much success, as far as 
I know. With the fast computers today, maybe the time has come again for 
real space refinement ...


Best regards,

Dirk.

Am 29.10.10 08:03, schrieb Robbie Joosten:

Hi Bart,

I agree with the building strategy you propose, but at some point it 
stops helping and a bit more attention to detail is needed. Reciprocal 
space refinement doesn't seem to do the fine details. It always 
surprises me how much atoms still move when you real-space refine a 
refined model, especially the waters. I admit this is not a fair 
comparison.


High resolution data helps, but better data makes it tempting to put 
too little effort in optimising the model. I've seen some horribly 
obvious errors in hi-res models (more than 10 sigma difference density 
peaks for misplaced side chains). At the same time there are quite a 
lot of low-res models that are exceptionally good.


Cheers,
Robbie

> Date: Thu, 28 Oct 2010 16:32:04 -0600
> From: bart.ha...@ualberta.ca
> Subject: Re: [ccp4bb] Against Method (R)
> To: CCP4BB@JISCMAIL.AC.UK
>
> On 10-10-28 04:09 PM, Ethan Merritt wrote:
> > This I can answer based on experience. One can take the coordinates 
from a structure
> > refined at near atomic resolution (~1.0A), including multiple 
conformations,
> > partial occupancy waters, etc, and use it to calculate R factors 
against a lower
> > resolution (say 2.5A) data set collected from an isomorphous 
crystal. The
> > R factors from this total-rigid-body replacement will be better 
than anything you
> > could get from refinement against the lower resolution data. In 
fact, refinement

> > from this starting point will just make the R factors worse.
> >
> > What this tells us is that the crystallographic residuals can 
recognize a
> > better model when they see one. But our refinement programs are not 
good
> > enough to produce such a better model in the first place. Worsr, 
they are not

> > even good enough to avoid degrading the model.
> >
> > That's essentially the same thing Bart said, perhaps a little more 
pessimistic :-)

> >
> > cheers,
> >
> > Ethan
> >
>
> Not pessimistic at all, just realistic and perhaps even optimistic for
> methods developers as apparently there is still quite a bit of progress
> that can be made by improving the "search strategy" during refinement.
>
> During manual refinement I normally tell students not to bother about
> translating/rotating/torsioning atoms by just a tiny bit to make it fit
> better. Likewise there is no point in moving atoms a little bit to
> correct a distorted bond or bond length. If it needed to move that
> little bit the refinement program would have done it for you. Look for
> discreet errors in the problematic residue or its neighbors: peptide
> flips, 120 degree changes in side chain dihedrals, etc. If you can find
> and fix one of those errors a lot of the stereochemical distortions and
> non-ideal fit to density surrounding that residue will suddenly
> disappear as well.
>
> The benefit of high resolution is that it is much easier to pick up and
> fix such errors (or not make them in the first place)
>
> Bart
>
> --
>
> 
>
> Bart Hazes (Associate Professor)
> Dept. of Medical Microbiology& Immunology
> University of Alberta
> 1-15 Medical Sciences Building
> Edmonton, Alberta
> Canada, T6G 2H7
> phone: 1-780-492-0042
> fax: 1-780-492-7521
>
> 


--

***
Dirk Kostrewa
Gene Center Munich, A5.07
Department of Biochemistry
Ludwig-Maximilians-Universität München
Feodor-Lynen-Str. 25
D-81377 Munich
Germany
Phone:  +49-89-2180-76845
Fax:+49-89-2180-76999
E-mail: kostr...@genzentrum.lmu.de
WWW:www.genzentrum.lmu.de
***