Re: [ccp4bb] Regarding the correct space group identification

[Andrew Leslie - MRC LMB]

Dear Sayan,

   For interest, the only other example I know of where 
diffraction images show two different space groups is presented in a paper by 
Zbyszek Dauter et al, Acta Cryst D61, 967-975, 2005, where crystals of the 
proteolytic domain of Lon contained superimposed orthorhombic and monoclinic 
lattices. At the time (2005) this was the first reported example for proteins 
and I have not come across another since then.

Best wishes,

Andrew

> On 28 Jul 2022, at 07:15, Sayan Saha  wrote:
> 
> Dear All,
> 
> We have collected home-source X-ray intensity data for a protein at 2.6 
> Angstrom. The data can be processed in either C2 (a=120, b=80, c=85 and 
> beta=115) or P222 (P22121, a=80, b=85, c=110). MR solution can be obtained in 
> both the space groups. However, the solution can be refined with an Rw/Rf of 
> 29/32% only. The protein is bound to a ligand (co-crystallization) for which 
> a clear density can be observed.
> 
> Any help and suggestion in this regard would be very helpful.
> 
> With best regards,
> Sayan Saha.
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

[ccp4bb] Spam email after sending mail to ccp4bb

[Andrew Leslie - MRC LMB]

Every time I send an email to ccp4bb, I get a spam email from 295981...@qq.com 
 that consists of a single line of Chinese (Japanese) 
characters, is anyone else getting this?

Thanks,

Andrew


To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] Regarding the correct space group identification

[Andrew Leslie - MRC LMB]

Dear Boaz,

 Yes, providing the two lattices belong to two discrete 
(separable) volumes of the crystal, then using a micro beam may help, but even 
then you run the risk of the lattice that is in the beam changing as you rotate 
the crystal. Given that the Rfree value is really not too high for the P222 
case, the model may well be good enough to answer the biological question that 
they are asking, so its a question of balancing the additional effort involved 
in trying a micro beam and the required quality of the final model.

Best wishes,

Andrew

> On 1 Aug 2022, at 17:55, Boaz Shaanan  wrote:
> 
> Dear Andrew,
> This is a great detective work of yours. Hoewver, since these are data 
> recorded at home, the obvious way out of this mess is to screen/collect data 
> at a synchrotron (as suggeted by Andrew Thompson) with a much smaller 
> oscillation range as pointed out by Phil.  The much smaller  irradiated 
> crystal volumes may enable to deal better with this nasty mixture of 
> lattices. 
> 
> This is of course assuming that a search for different crystallization 
> conditions has been exhausted. 
> 
> Cheers,
> Boaz
> 
> Boaz Shaanan, Ph.D.
> Dept. of Life Sciences
> Ben Gurion University
> Beer Sheva, Israel
> 
> On Aug 1, 2022 18:24, Andrew Leslie - MRC LMB  
> wrote:
> Dear Sayan,
> 
>I believe that I have found the answer to your problem. 
> When I tried indexing using images 1 & 2 (90° apart in phi) I could only find 
> an  orthorhombic solution, there was no suggestion of a C2 solution. As 
> Eleanor, Land and myself have already pointed out, the P222 cell and the C2 
> cell that you provided in your first email cannot be interconverted, so there 
> was obviously an issue because you were able to integrate the C2 cell giving 
> a MR solution and a model with similar R-factors.
> 
> When I tried the multiple lattice indexing in imosflm with 6 images, phi 
> values of 0,30,60,90,120 and 150 it immediately found two lattices, the C2 
> cell and the P222 cell that you described. Thus your crystal is actually made 
> up of two distinct components with different spacegroups. I believe that 
> Zbyszek Dauter has published a similar example.
> 
> The problem then is that many of the spots from the two lattices overlap on 
> the detector, so the measured intensity will not be correct for either 
> lattice. This will account for the high R-factors that you observe. 
> 
> Unfortunately, the strength of the diffraction from the two different 
> lattices can vary as the crystal rotates, depending on the volume of each 
> lattice that is in the beam. This is why indexing with just 2 images, at 0 
> and 90°, gives no indication of the C2 cell.
> 
> I do not believe that there is any integration package that will allow you to 
> “deconvolute” the intensities from the two different lattices where they 
> overlap. imosflm gives you the opportunity to integrate one lattice and 
> ignore any spots in that lattice that are overlapped by the second lattice, 
> but this can lead to quite incomplete data. Often the best way to deal with 
> this situation is to ignore one of the lattices and just integrate the other, 
> and if the volume of that lattice in the beam is greater (ie the spots are 
> stronger) this can give a good model. In your case the diffraction from the 
> P222 lattice seems to be stronger (gives lower R-factors for the refined 
> model). You can check the quality of the model by looking at the density for 
> atoms that are not included in the model (eg the ligand), or by deleting some 
> residues and seeing how well the density comes back.
> 
> Best wishes,
> 
> Andrew
> 
>> On 29 Jul 2022, at 12:17, Sayan Saha > <mailto:ssaha43...@gmail.com>> wrote:
>> 
>> Dear Sir,
>> 
>> The Rw/Rf for P22121 structure solution is ~29/32%. For C2 structure 
>> solution, it is a little higher, 32/35%.
>> 
>> 
>> With best regards,
>> Sayan Saha.
>> 
>> 
>> 
>> 
>> 
>> On Fri, Jul 29, 2022 at 3:25 PM Andrew Leslie - MRC LMB 
>> mailto:and...@mrc-lmb.cam.ac.uk>> wrote:
>> Dear Sayan,
>>  
>>Using imosflm, based on the two images that you have 
>> uploaded, the cell appears to be orthorhombic (approx 80, 85, 111) and there 
>> is no evidence for the C2 unit call that you suggested. Using only the 
>> second image there is a C2 solution, but the prediction is very poor (high 
>> positional error). I am therefore a bit surprised that you found a MR 
>> solution in C2. Were the Rfactors that you quoted (29/32%) for the 
>> orthorhombic solution or the C2 solution?
>> 
>> As Herman poin

Re: [ccp4bb] Regarding the correct space group identification

[Andrew Leslie - MRC LMB]

Dear Sayan,

   I believe that I have found the answer to your problem. When 
I tried indexing using images 1 & 2 (90° apart in phi) I could only find an  
orthorhombic solution, there was no suggestion of a C2 solution. As Eleanor, 
Land and myself have already pointed out, the P222 cell and the C2 cell that 
you provided in your first email cannot be interconverted, so there was 
obviously an issue because you were able to integrate the C2 cell giving a MR 
solution and a model with similar R-factors.

When I tried the multiple lattice indexing in imosflm with 6 images, phi values 
of 0,30,60,90,120 and 150 it immediately found two lattices, the C2 cell and 
the P222 cell that you described. Thus your crystal is actually made up of two 
distinct components with different spacegroups. I believe that Zbyszek Dauter 
has published a similar example.

The problem then is that many of the spots from the two lattices overlap on the 
detector, so the measured intensity will not be correct for either lattice. 
This will account for the high R-factors that you observe. 

Unfortunately, the strength of the diffraction from the two different lattices 
can vary as the crystal rotates, depending on the volume of each lattice that 
is in the beam. This is why indexing with just 2 images, at 0 and 90°, gives no 
indication of the C2 cell.

I do not believe that there is any integration package that will allow you to 
“deconvolute” the intensities from the two different lattices where they 
overlap. imosflm gives you the opportunity to integrate one lattice and ignore 
any spots in that lattice that are overlapped by the second lattice, but this 
can lead to quite incomplete data. Often the best way to deal with this 
situation is to ignore one of the lattices and just integrate the other, and if 
the volume of that lattice in the beam is greater (ie the spots are stronger) 
this can give a good model. In your case the diffraction from the P222 lattice 
seems to be stronger (gives lower R-factors for the refined model). You can 
check the quality of the model by looking at the density for atoms that are not 
included in the model (eg the ligand), or by deleting some residues and seeing 
how well the density comes back.

Best wishes,

Andrew

> On 29 Jul 2022, at 12:17, Sayan Saha  wrote:
> 
> Dear Sir,
> 
> The Rw/Rf for P22121 structure solution is ~29/32%. For C2 structure 
> solution, it is a little higher, 32/35%.
> 
> 
> With best regards,
> Sayan Saha.
> 
> 
> 
> 
> 
> On Fri, Jul 29, 2022 at 3:25 PM Andrew Leslie - MRC LMB 
> mailto:and...@mrc-lmb.cam.ac.uk>> wrote:
> Dear Sayan,
>  
>Using imosflm, based on the two images that you have 
> uploaded, the cell appears to be orthorhombic (approx 80, 85, 111) and there 
> is no evidence for the C2 unit call that you suggested. Using only the second 
> image there is a C2 solution, but the prediction is very poor (high 
> positional error). I am therefore a bit surprised that you found a MR 
> solution in C2. Were the Rfactors that you quoted (29/32%) for the 
> orthorhombic solution or the C2 solution?
> 
> As Herman pointed out, there is definite streaking in some lunes on image 2, 
> but this seems to be restricted to a relatively small part of the diffraction 
> pattern. While this does indicate some kind of disorder, I do not think this 
> is serious enough to prevent a reliable structure determination, but it might 
> account for the slightly high R-factors.
> 
> There is definitely a lot of spot overlap, as the mosaic spread (mosflm 
> definition) is in the region of 1.5°. The oscillation angle would have to be 
> 0.3° or less to avoid this spot overlap (determined from the Strategy option 
> in imosflm). Again, as Kay pointed out, this would lead to higher then 
> expected R-factors. As this is an image plate detector, I can understand why 
> you might not be using an oscillation angle of 0.1°, but you do need to check 
> that the oscillation angle you are using does not give rise to a lot of 
> spatial overlaps and a smaller oscillation angle will generally give improved 
>  quality data, especially if the background level is quite high, as it is in 
> your images.
> 
> Best wishes,
> 
> Andrew
> 
>> On 29 Jul 2022, at 05:06, Sayan Saha > <mailto:ssaha43...@gmail.com>> wrote:
>> 
>> Dear Sir,
>> 
>>  image1.osc 
>> <https://drive.google.com/file/d/1K5hhoMymVyidOjZyR5Hbfb8ny-KkMIm6/view?usp=drive_web>
>>  image2.osc 
>> <https://drive.google.com/file/d/16TsGwBPtrkVxOYN7M5PxvJyS0pvMljVZ/view?usp=drive_web>
>> The detector-to-crystal distance was 190 mm. The Oscillation range was 1.0 
>> degree. Please find attached two diffraction images.
>> With best regards,
>> Sayan Saha.
>

Re: [ccp4bb] Regarding the correct space group identification

[Andrew Leslie - MRC LMB]

Dear Sayan,

I find this really surprising. According to the ccp4 program 
“othercell” the two cells that you specify (C2 and P222) are NOT compatible, ie 
they cannot both give correct predictions for the diffraction. This is, of 
course, only based on the two images that have been provided, but it does 
suggest that something rather strange is happening. Can you upload a few other 
images, eg rotated 30° and 60° fro image 1 that you uploaded previously?

Best wishes,

Andrew

> On 29 Jul 2022, at 12:17, Sayan Saha  wrote:
> 
> Dear Sir,
> 
> The Rw/Rf for P22121 structure solution is ~29/32%. For C2 structure 
> solution, it is a little higher, 32/35%.
> 
> 
> With best regards,
> Sayan Saha.
> 
> 
> 
> 
> 
> On Fri, Jul 29, 2022 at 3:25 PM Andrew Leslie - MRC LMB 
> mailto:and...@mrc-lmb.cam.ac.uk>> wrote:
> Dear Sayan,
>  
>Using imosflm, based on the two images that you have 
> uploaded, the cell appears to be orthorhombic (approx 80, 85, 111) and there 
> is no evidence for the C2 unit call that you suggested. Using only the second 
> image there is a C2 solution, but the prediction is very poor (high 
> positional error). I am therefore a bit surprised that you found a MR 
> solution in C2. Were the Rfactors that you quoted (29/32%) for the 
> orthorhombic solution or the C2 solution?
> 
> As Herman pointed out, there is definite streaking in some lunes on image 2, 
> but this seems to be restricted to a relatively small part of the diffraction 
> pattern. While this does indicate some kind of disorder, I do not think this 
> is serious enough to prevent a reliable structure determination, but it might 
> account for the slightly high R-factors.
> 
> There is definitely a lot of spot overlap, as the mosaic spread (mosflm 
> definition) is in the region of 1.5°. The oscillation angle would have to be 
> 0.3° or less to avoid this spot overlap (determined from the Strategy option 
> in imosflm). Again, as Kay pointed out, this would lead to higher then 
> expected R-factors. As this is an image plate detector, I can understand why 
> you might not be using an oscillation angle of 0.1°, but you do need to check 
> that the oscillation angle you are using does not give rise to a lot of 
> spatial overlaps and a smaller oscillation angle will generally give improved 
>  quality data, especially if the background level is quite high, as it is in 
> your images.
> 
> Best wishes,
> 
> Andrew
> 
>> On 29 Jul 2022, at 05:06, Sayan Saha > <mailto:ssaha43...@gmail.com>> wrote:
>> 
>> Dear Sir,
>> 
>>  image1.osc 
>> <https://drive.google.com/file/d/1K5hhoMymVyidOjZyR5Hbfb8ny-KkMIm6/view?usp=drive_web>
>>  image2.osc 
>> <https://drive.google.com/file/d/16TsGwBPtrkVxOYN7M5PxvJyS0pvMljVZ/view?usp=drive_web>
>> The detector-to-crystal distance was 190 mm. The Oscillation range was 1.0 
>> degree. Please find attached two diffraction images.
>> With best regards,
>> Sayan Saha.
>> 
>> On Thu, Jul 28, 2022 at 9:41 PM Sayan Saha > <mailto:ssaha43...@gmail.com>> wrote:
>> Dear Sir,
>> 
>> The detector-to-crystal distance was 190 mm. The Oscillation range was 1.0 
>> degree. Please find attached two diffraction images.
>> With best regards,
>> Sayan Saha.
>> 
>> 
>> On Thu, Jul 28, 2022 at 7:31 PM Kay Diederichs 
>> mailto:kay.diederi...@uni-konstanz.de>> 
>> wrote:
>> Dear Sayan,
>> 
>> On Thu, 28 Jul 2022 15:12:30 +0530, Sayan Saha > <mailto:ssaha43...@gmail.com>> wrote:
>> 
>> >Dear Sir,
>> >
>> >1. There are no ice-rings. However, diffraction spots seem to be
>> >overlapping. This can be seen during the data processing, as the space
>> >group (C2 or P222) varies even in the consecutive frames.
>> 
>> spot overlap results in inaccurate intensity values. Inaccurate intensities 
>> result in high Rwork/Rfree.
>> 
>> Why do the spots overlap? High mosaicity? Detector distance too small? 
>> Oscillation range too high (0.1° is typically adequate)?
>> 
>> It would be good to see the data, otherwise we can only speculate.
>> 
>> Space group does not change from one frame to the next. If you use XDS, a 
>> good guide to decide between higher and lower-symmetry space groups is to 
>> compare their ISa values.
>> 
>> best,
>> Kay
>> 
>> >
>> >2. Crystal packing of C2 and P22121 seem to be similar (please see the
>> >attached images).
>> >
>> >3. Forgot to mention in my previous email that we have already processed
>> >the 

Re: [ccp4bb] Regarding the correct space group identification

[Andrew Leslie - MRC LMB]

Dear Sayan,
 
   Using imosflm, based on the two images that you have 
uploaded, the cell appears to be orthorhombic (approx 80, 85, 111) and there is 
no evidence for the C2 unit call that you suggested. Using only the second 
image there is a C2 solution, but the prediction is very poor (high positional 
error). I am therefore a bit surprised that you found a MR solution in C2. Were 
the Rfactors that you quoted (29/32%) for the orthorhombic solution or the C2 
solution?

As Herman pointed out, there is definite streaking in some lunes on image 2, 
but this seems to be restricted to a relatively small part of the diffraction 
pattern. While this does indicate some kind of disorder, I do not think this is 
serious enough to prevent a reliable structure determination, but it might 
account for the slightly high R-factors.

There is definitely a lot of spot overlap, as the mosaic spread (mosflm 
definition) is in the region of 1.5°. The oscillation angle would have to be 
0.3° or less to avoid this spot overlap (determined from the Strategy option in 
imosflm). Again, as Kay pointed out, this would lead to higher then expected 
R-factors. As this is an image plate detector, I can understand why you might 
not be using an oscillation angle of 0.1°, but you do need to check that the 
oscillation angle you are using does not give rise to a lot of spatial overlaps 
and a smaller oscillation angle will generally give improved  quality data, 
especially if the background level is quite high, as it is in your images.

Best wishes,

Andrew

> On 29 Jul 2022, at 05:06, Sayan Saha  wrote:
> 
> Dear Sir,
> 
>  image1.osc 
> 
>  image2.osc 
> 
> The detector-to-crystal distance was 190 mm. The Oscillation range was 1.0 
> degree. Please find attached two diffraction images.
> With best regards,
> Sayan Saha.
> 
> On Thu, Jul 28, 2022 at 9:41 PM Sayan Saha  > wrote:
> Dear Sir,
> 
> The detector-to-crystal distance was 190 mm. The Oscillation range was 1.0 
> degree. Please find attached two diffraction images.
> With best regards,
> Sayan Saha.
> 
> 
> On Thu, Jul 28, 2022 at 7:31 PM Kay Diederichs 
> mailto:kay.diederi...@uni-konstanz.de>> 
> wrote:
> Dear Sayan,
> 
> On Thu, 28 Jul 2022 15:12:30 +0530, Sayan Saha  > wrote:
> 
> >Dear Sir,
> >
> >1. There are no ice-rings. However, diffraction spots seem to be
> >overlapping. This can be seen during the data processing, as the space
> >group (C2 or P222) varies even in the consecutive frames.
> 
> spot overlap results in inaccurate intensity values. Inaccurate intensities 
> result in high Rwork/Rfree.
> 
> Why do the spots overlap? High mosaicity? Detector distance too small? 
> Oscillation range too high (0.1° is typically adequate)?
> 
> It would be good to see the data, otherwise we can only speculate.
> 
> Space group does not change from one frame to the next. If you use XDS, a 
> good guide to decide between higher and lower-symmetry space groups is to 
> compare their ISa values.
> 
> best,
> Kay
> 
> >
> >2. Crystal packing of C2 and P22121 seem to be similar (please see the
> >attached images).
> >
> >3. Forgot to mention in my previous email that we have already processed
> >the data in P1 and MR solution could be found only in P1 (Phaser was used
> >with an option in all possible space groups of that point group).
> >
> >Please let me know if any other information is required.
> >
> >With best regards,
> >Sayan Saha.
> >
> >
> >On Thu, Jul 28, 2022 at 1:26 PM Schreuder, Herman /DE <
> >herman.schreu...@sanofi.com > wrote:
> >
> >> Dear Sayan,
> >>
> >>
> >>
> >> If a subunit is correctly oriented, but the translation is incorrect,
> >> density for a ligand may still show up in the binding site of the protein.
> >> It might be that one of the 2-fold axes, you think is crystallographic, is
> >> in fact non crystallographic and a few Angstroms away from the
> >> crystallographic position.
> >>
> >>
> >>
> >> What I would do:
> >>
> >>1. Check the images: are there ice-rings or other artifacts that could
> >>cause scaling problems that would lead to high Rw/Rf values? In that 
> >> case,
> >>there is not much you can do.
> >>2. Compare the C2 and P22121 solutions: do they have the same overall
> >>crystal packing (CS+NCS), or are they different? Do they have the same
> >>Rw/Rf values? Can we learn anything from the differences in overall 
> >> crystal
> >>packing?
> >>3. Process, run MR and refine in P1. Do you get lower R-factors? If
> >>so, then run Zanuda to find out the real space group.
> >>
> >>
> >>
> >> Best,
> >>
> >> Herman
> >>
> >>
> >>
> >> *Von:* CCP4 bulletin board  >> > *Im Auftrag von *Sayan
> >> Saha

Re: [ccp4bb] Regarding the correct space group identification

[Andrew Leslie - MRC LMB]

Dear Sayan,

I could be wrong, but perhaps Kay was asking you to provide 
the actual images, rather than jpeg images. One can usually get a lot more 
information by processing the actual images rather than looking at the jpegs.

Best wishes,

Andrew

> On 28 Jul 2022, at 17:11, Sayan Saha  wrote:
> 
> Dear Sir,
> 
> The detector-to-crystal distance was 190 mm. The Oscillation range was 1.0 
> degree. Please find attached two diffraction images.
> With best regards,
> Sayan Saha.
> 
> 
> On Thu, Jul 28, 2022 at 7:31 PM Kay Diederichs 
> mailto:kay.diederi...@uni-konstanz.de>> 
> wrote:
> Dear Sayan,
> 
> On Thu, 28 Jul 2022 15:12:30 +0530, Sayan Saha  > wrote:
> 
> >Dear Sir,
> >
> >1. There are no ice-rings. However, diffraction spots seem to be
> >overlapping. This can be seen during the data processing, as the space
> >group (C2 or P222) varies even in the consecutive frames.
> 
> spot overlap results in inaccurate intensity values. Inaccurate intensities 
> result in high Rwork/Rfree.
> 
> Why do the spots overlap? High mosaicity? Detector distance too small? 
> Oscillation range too high (0.1° is typically adequate)?
> 
> It would be good to see the data, otherwise we can only speculate.
> 
> Space group does not change from one frame to the next. If you use XDS, a 
> good guide to decide between higher and lower-symmetry space groups is to 
> compare their ISa values.
> 
> best,
> Kay
> 
> >
> >2. Crystal packing of C2 and P22121 seem to be similar (please see the
> >attached images).
> >
> >3. Forgot to mention in my previous email that we have already processed
> >the data in P1 and MR solution could be found only in P1 (Phaser was used
> >with an option in all possible space groups of that point group).
> >
> >Please let me know if any other information is required.
> >
> >With best regards,
> >Sayan Saha.
> >
> >
> >On Thu, Jul 28, 2022 at 1:26 PM Schreuder, Herman /DE <
> >herman.schreu...@sanofi.com > wrote:
> >
> >> Dear Sayan,
> >>
> >>
> >>
> >> If a subunit is correctly oriented, but the translation is incorrect,
> >> density for a ligand may still show up in the binding site of the protein.
> >> It might be that one of the 2-fold axes, you think is crystallographic, is
> >> in fact non crystallographic and a few Angstroms away from the
> >> crystallographic position.
> >>
> >>
> >>
> >> What I would do:
> >>
> >>1. Check the images: are there ice-rings or other artifacts that could
> >>cause scaling problems that would lead to high Rw/Rf values? In that 
> >> case,
> >>there is not much you can do.
> >>2. Compare the C2 and P22121 solutions: do they have the same overall
> >>crystal packing (CS+NCS), or are they different? Do they have the same
> >>Rw/Rf values? Can we learn anything from the differences in overall 
> >> crystal
> >>packing?
> >>3. Process, run MR and refine in P1. Do you get lower R-factors? If
> >>so, then run Zanuda to find out the real space group.
> >>
> >>
> >>
> >> Best,
> >>
> >> Herman
> >>
> >>
> >>
> >> *Von:* CCP4 bulletin board  >> > *Im Auftrag von *Sayan
> >> Saha
> >> *Gesendet:* Donnerstag, 28. Juli 2022 08:15
> >> *An:* CCP4BB@JISCMAIL.AC.UK 
> >> *Betreff:* [ccp4bb] Regarding the correct space group identification
> >>
> >>
> >>
> >> Dear All,
> >>
> >>
> >>
> >> We have collected home-source X-ray intensity data for a protein at 2.6
> >> Angstrom. The data can be processed in either C2 (a=120, b=80, c=85 and
> >> beta=115) or P222 (P22121, a=80, b=85, c=110). MR solution can be obtained
> >> in both the space groups. However, the solution can be refined with an
> >> Rw/Rf of 29/32% only. The protein is bound to a ligand (co-crystallization)
> >> for which a clear density can be observed.
> >>
> >>
> >>
> >> Any help and suggestion in this regard would be very helpful.
> >>
> >>
> >>
> >> With best regards,
> >>
> >> Sayan Saha.
> >>
> >>
> >>
> >>
> >> --
> >>
> >> To unsubscribe from the CCP4BB list, click the following link:
> >> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> >> 
> >>
> >
> >
> >
> >To unsubscribe from the CCP4BB list, click the following link:
> >https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> >
> >
> >This message was issued to members of www.jiscmail.ac.uk/CCP4BB 
> >, a mailing list hosted by 
> >www.jiscmail.ac.uk , terms & conditions are 
> >available at https://www.jiscmail.ac.uk/policyandsecurity/ 
> >
> >
> 
> 

Re: [ccp4bb] Comparing two datasets

[Andrew Leslie - MRC LMB]

I think that POINTLESS works with intensities rather than structure factors 
(I’m not sure if this can be changed). Also, SCALEIT gives a much more detailed 
breakdown (R factors as a function of resolution and differences in terms of 
sigmas etc) than POINTLESS WILL.

Cheers,

Andrew

> On 26 Jul 2022, at 09:24, LEGRAND Pierre 
>  wrote:
> 
> Hello Mirek,
> 
> A very quick approach for that is offered by pointless:
> 
> pointless HKLREF 1_1_aimless.mtz  HKLIN 2_1_aimless.mtz
> or
> pointless HKLREF 1_1_aimless.mtz  XDSIN XDS_ASCII.HK
> 
> You will obtain a table looking like that, taking into account to possible 
> reindexing:
> 
> Alternative indexing scores relative to reference
>Alternative reindexingLklhd  CC R(E^2)Number 
> Cell_deviation
>  1  [h,k,l]  0.9930.9620.118 19150  
> 0.08
>  2  [-k,h,l] 0.0070.0780.512 19150  
> 0.87
> 
> 
> Best wishes,
> 
> Pierre Legrand
> PROXIMA-1 Beamline
> Synchrotron SOLEIL
> 
> De: "Nicolas Foos" 
> À: CCP4BB@JISCMAIL.AC.UK
> Envoyé: Mardi 26 Juillet 2022 08:36:35
> Objet: Re: [ccp4bb] Comparing two datasets
> 
> Hi Mirek, 
> 
> I am pretty sure XSCALE will do that for you : 
> https://xds.mr.mpg.de/html_doc/xscale_program.html 
> 
> If not, maybe have a look on SHELXC in SIR mode. 
> 
> Hope this help. 
> 
> Nicolas
> 
> On 25/07/2022 21:52, Cygler, Miroslaw wrote:
> Hi,
> I would like to calculate the R-merge for Fs from two datasets processed from 
> two different crystals. Tried to use Blend but got the message that Blend 
> requires R. Downloaded R but do not know how to tell CCP4 where it is located 
> on my Mac. Is there another program that would take two mtg files and merge 
> the Fs?
> Any help would be greatly appreciated. 
> 
> 
> Mirek
> 
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 
> -- 
> Nicolas Foos PhD - ARISE fellow
> https://orcid.org/-0003-2331-8399 
>
> EMBL Grenoble, McCarthy Team
> 71 av. des Martyrs, 
> 38000 Grenoble FRANCE
>
> +33 4 57 42 84 67
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] Comparing two datasets

[Andrew Leslie - MRC LMB]

I think that SCALEIT should be able to do this. This was originally designed to 
compare Fs for Native and heavy atom derivate data, but can compare any two 
similar datasets (ie those that can sensibly be scaled together). You will need 
to merge the two mtz files first.

Cheers,

Andrew

> On 25 Jul 2022, at 20:52, Cygler, Miroslaw  wrote:
> 
> Hi,
> I would like to calculate the R-merge for Fs from two datasets processed from 
> two different crystals. Tried to use Blend but got the message that Blend 
> requires R. Downloaded R but do not know how to tell CCP4 where it is located 
> on my Mac. Is there another program that would take two mtg files and merge 
> the Fs?
> Any help would be greatly appreciated. 
> 
> 
> Mirek
> 
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] Strange crystal packing in twined crystal

[Andrew Leslie - MRC LMB]

Dear Florian,

 There have been previous examples where there are distinct 
“layers” of protein packing without any obvious density linking the layers, as 
it appears in the image you show. One is tyrosyl tRNA synthetase, where the 
layers were in fact linked by a disordered domain for which there was no 
density. Does the density that you see account for the entire protein (or 
complex) that you have crystallised?

I am fairly sure that this has also been seen for membrane proteins, where the 
extra-membrane component (or an additional protein, eg a Fab) has been 
disordered, again giving layers of density that appear unconnected.

I’m not sure what you mean by “having two distinct lattices”. Do the 
diffraction images show any signs of disorder, eg diffuse streaking or features 
that are not accounted for by the lattice used when integrating the data?

Best wishes,

Andrew

> On 21 Jul 2022, at 19:29, Schubot, Florian  wrote:
> 
> Hi, I have a high-resolution data set ~1.6 Angst.) for a twinned crystal (SG 
> C2, twin law h,-k,-l). The structure was solved via molecular replacement. 
> The map and model look excellent but R and Rfree continue to hover around 
> 30%. I do use twinned refinement. Reviewing the packing, I noticed a huge gap 
> between layers (picture below). There is NO additional well-defined protein 
> density in this gap. I this gap is a symptom of having two distinct lattices. 
> I was curious if anyone could advise/comment.
> Thank you,
> Florian
> 
> 
> 
> =
> Florian Schubot, Ph.D.
>  
> Associate Professor
> Virginia Polytechnic Institute and State University
> Department of Biological Sciences
> 5002 Derring Hall
> 926 West Campus Dr
> Blacksburg, VA 24061
> United States
> E-mail: fschu...@vt.edu 
> Phone: (540) 231-2393
> Fax: (540) 231.4043
> http://www.faculty.biol.vt.edu/schubot/ 
> 
> =
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

[ccp4bb] Bug when running imosflm under Mac OS Monterey

[Andrew Leslie - MRC LMB]

When running imosflm under Mac OS Monterey, the program gives an X error:

X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  45 (X_OpenFont)
  Value in failed request:  0x60005c
  Serial number of failed request:  1474
  Current serial number in output stream:  1475

This is because of some incompatabiity in fonts between the version of Tcl used 
with imosflm and the Monterey operating system.

To fix this error, edit the file imosflm.tcl in the directory similar to:

/ccp4-7.1/share/ccp4i/imosflm/src

Be sure to edit this file and not the one with the same name in the directory 
above.

In lines 431 to 442 (this is in version 7.4.0, line numbers may differ in 
earlier versions but text will be the same), change all occurences of 
"helvetica" to "-adobe-helvetica". These lines are currently:

font create font_l -family helvetica -size $normal_font_size -weight normal
font create font_b -family helvetica -size $normal_font_size -weight bold
font create font_i -family helvetica -size $small_font_size -weight normal 
-slant italic
font create font_e -family courier -size $normal_font_size -weight normal
font create font_s -family helvetica -size $small_font_size -weight normal
font create font_t -family helvetica -size $tiny_font_size -weight normal
font create font_tb -family helvetica -size $tiny_font_size -weight bold
font create font_g -family symbol -size $normal_font_size -weight normal
font create font_u -family helvetica -size $normal_font_size -weight normal 
-underline 1
font create subtitle_font -family helvetica -size $subtitle_font_size -weight 
bold
font create title_font -family helvetica -size $title_font_size -weight bold
font create huge_font -family helvetica -size $huge_font_size -weight bold

I am indebted to David Aragao for providing this fix.


All current bug fixes are listed on the imosflm web page:

https://www.mrc-lmb.cam.ac.uk/mosflm/imosflm/ver740/introduction.html 
<https://www.mrc-lmb.cam.ac.uk/mosflm/imosflm/ver740/introduction.html>


Andrew Leslie


To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

[ccp4bb] Bug in starting the CCP4 distributed version of imosflm in latest CCP4 Updates (7.0.017 and 7.1.018)

[Andrew Leslie - MRC LMB]

The latest version of imosflm (7.4.0) was included in the ccp4 Update 7.0.17 
released 11th Nov 2021. Unfortunately there is an error in the startup script, 
which will result in the following error message:

Error in startup script: extra characters after close-quote
while executing
"set ::env(IMOSFLM_VERSION) "iMosflm version 7.4.0, 16th September 2021”"


The error is in the file imosflm.tcl, which will be in a directory similar to:
/ccp4-7.1/share/ccp4i/imosflm/imosflm.tcl

(the full directory will depend on the installation).

To fix this error, simply edit line 145 of “imosflm.tcl” to remove the second 
double quote at the end of that line.

Explicitly, change:
set ::env(IMOSFLM_VERSION) "iMosflm version 7.4.0, 16th September 2021”"

to:
set ::env(IMOSFLM_VERSION) "iMosflm version 7.4.0, 16th September 2021”


This does not affect version 7.4.0 of imosflm if this was installed using the 
LMB website (which uses a different startup script).

Andrew Leslie


To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] am I doing this right?

[Andrew Leslie - MRC LMB]

Hi Ian, James,

  I have a strong feeling that I have seen this result 
before, and it was due to Andy Hammersley at ESRF. I’ve done a literature 
search and there is a paper relating to errors in analysis of counting 
statistics (se below), but I had a quick look at this and could not find the 
(N+1) correction, so it must have been somewhere else. I Have cc’d Andy on this 
Email (hoping that this Email address from 2016 still works) and maybe he can 
throw more light on this. What I remember at the time I saw this was the 
simplicity of the correction.

Cheers,

Andrew

Reducing bias in the analysis of counting statistics data

Hammersley, AP  
(Hammersley, AP) Antoniadis, A 
 (Antoniadis, A)

NUCLEAR INSTRUMENTS & METHODS IN PHYSICS RESEARCH SECTION A-ACCELERATORS 
SPECTROMETERS DETECTORS AND ASSOCIATED EQUIPMENT

Volume

394

Issue

1-2
Page

219-224
DOI

10.1016/S0168-9002(97)00668-2
Published

JUL 11 1997

> On 12 Oct 2021, at 18:55, Ian Tickle  wrote:
> 
> 
> Hi James
> 
> What the Poisson distribution tells you is that if the true count is N then 
> the expectation and variance are also N.  That's not the same thing as saying 
> that for an observed count N the expectation and variance are N.  Consider 
> all those cases where the observed count is exactly zero.  That can arise 
> from any number of true counts, though as you noted larger values become 
> increasingly unlikely.  However those true counts are all >= 0 which means 
> that the mean and variance of those true counts must be positive and 
> non-zero.  From your results they are both 1 though I haven't been through 
> the algebra to prove it.
> 
> So what you are saying seems correct: for N observed counts we should be 
> taking the best estimate of the true value and variance as N+1.  For 
> reasonably large N the difference is small but if you are concerned with weak 
> images it might start to become significant.
> 
> Cheers
> 
> -- Ian
> 
> 
> On Tue, 12 Oct 2021 at 17:56, James Holton  > wrote:
> All my life I have believed that if you're counting photons then the 
> error of observing N counts is sqrt(N).  However, a calculation I just 
> performed suggests its actually sqrt(N+1).
> 
> My purpose here is to understand the weak-image limit of data 
> processing. Question is: for a given pixel, if one photon is all you 
> got, what do you "know"?
> 
> I simulated millions of 1-second experiments. For each I used a "true" 
> beam intensity (Itrue) between 0.001 and 20 photons/s. That is, for 
> Itrue= 0.001 the average over a very long exposure would be 1 photon 
> every 1000 seconds or so. For a 1-second exposure the observed count (N) 
> is almost always zero. About 1 in 1000 of them will see one photon, and 
> roughly 1 in a million will get N=2. I do 10,000 such experiments and 
> put the results into a pile.  I then repeat with Itrue=0.002, 
> Itrue=0.003, etc. All the way up to Itrue = 20. At Itrue > 20 I never 
> see N=1, not even in 1e7 experiments. With Itrue=0, I also see no N=1 
> events.
> Now I go through my pile of results and extract those with N=1, and 
> count up the number of times a given Itrue produced such an event. The 
> histogram of Itrue values in this subset is itself Poisson, but with 
> mean = 2 ! If I similarly count up events where 2 and only 2 photons 
> were seen, the mean Itrue is 3. And if I look at only zero-count events 
> the mean and standard deviation is unity.
> 
> Does that mean the error of observing N counts is really sqrt(N+1) ?
> 
> I admit that this little exercise assumes that the distribution of Itrue 
> is uniform between 0.001 and 20, but given that one photon has been 
> observed Itrue values outside this range are highly unlikely. The 
> Itrue=0.001 and N=1 events are only a tiny fraction of the whole.  So, I 
> wold say that even if the prior distribution is not uniform, it is 
> certainly bracketed. Now, Itrue=0 is possible if the shutter didn't 
> open, but if the rest of the detector pixels have N=~1, doesn't this 
> affect the prior distribution of Itrue on our pixel of interest?
> 
> Of course, two or more photons are better than one, but these days with 
> small crystals and big detectors N=1 is no longer a trivial situation.  
> I look forward to hearing your take on this.  And no, this is not a trick.
> 
> -James Holton
> MAD Scientist
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB 
> , a mailing list hosted by 
> www.jiscmail.ac.uk , terms & conditions are 
> 

[ccp4bb] Re-Release of iMosflm version 7.4.0

[Andrew Leslie - MRC LMB]

Dear All,

Version 7.4.0 of iMosflm has just been re-released and can be downloaded from:

https://www.mrc-lmb.cam.ac.uk/mosflm/imosflm/ver740/introduction.html 
<https://www.mrc-lmb.cam.ac.uk/mosflm/imosflm/ver740/introduction.html>

*** Note that the Windows version will not process HDF5 images (from Eiger 
detectors) that have been written using HDF5 version 10.5. This will include 
images from many Diamond Light Source beam lines (and possibly others). The 
Linux and Mac OSX versions are not affected by this issue in this re-release. A 
message will be sent to CCP4BB  when this has been resolved. ***

This version has improved integration for very weak images, new guidance for 
processing electron diffraction images (in the tutorial), allows processing of 
CBF style images for Bruker Photon II or Photon III detectors and pck format 
from the Oxford diffraction Crysalis detector. There is also improved 
processing for spots that lie close to the tile boundaries in Eiger (or 
Pilatus) detectors. A number of bugs have also been fixed.

Packages for Linux, OSX and Windows are available.

Please note that versions of 7.4.0 that have been available on this website for 
the last ~2-3 months have been beta versions and should now be replaced with 
the latest version. 

Andrew Leslie




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

[ccp4bb] iMosflm version 7.4.0 release withdrawn

[Andrew Leslie - MRC LMB]

A bug has come to light in reading some hdf5 files (from Eiger detectors) in 
the latest version of mosflm (7.4.0) . the program will stop with an error 
message when attempting to read the hdf5 file. I have therefore blocked the 
download site until this has been fixed.

I will send a new message to the bulletin board when this has been done.

Apologies to anyone affected by this,

Andrew Leslie


To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

[ccp4bb] New iMosflm release, version 7.4.0

[Andrew Leslie - MRC LMB]

Dear All,

A new version of iMosflm (7.4.0) has just been released. It can be downloaded 
from:

https://www.mrc-lmb.cam.ac.uk/mosflm/imosflm/ver740/introduction.html 
<https://www.mrc-lmb.cam.ac.uk/mosflm/imosflm/ver740/introduction.html>

This version has improved integration for very weak images, new guidance for 
processing electron diffraction images (in the tutorial), allows processing of 
CBF style images for Bruker Photon II or Photon III detectors and pck format 
from the Oxford diffraction Crysalis detector. There is also improved 
processing for spots that lie close to the tile boundaries in Eiger (or 
Pilatus) detectors. A number of bugs have also been fixed.

Packages for Linux, OSX and Windows are available.

Please note that versions of 7.4.0 that have been available on this website for 
the last ~2-3 months have been beta versions and should now be replaced with 
the latest version. 

Andrew Leslie




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] AW: [ccp4bb] Antwort: Re: [ccp4bb] chain on 2-fold axis?

[Andrew Leslie - MRC LMB]

Dear Kay and Jon,

I cannot remember Ian Tickles original posting on this (assuming that it was 
made to the bulletin board), but surely the resolution of the data is also a 
very important factor in the danger of over-fitting. The lower the resolution, 
the worse the experimental data to refined parameter ratio becomes, and the 
more likely it is to obtain an overfitted model, regardless of how accurate 
that data might be. Perhaps this is why Kay said “generally I agree that the 
accuracy of the data is inversely related to the danger of overfitting”, or did 
you have something else in mind Kay?

Cheers,

Andrew

> On 30 Aug 2021, at 13:59, Kay Diederichs  
> wrote:
> 
> Hi Jon,
> 
> generally I agree that the accuracy of the data is inversely related to the 
> danger of overfitting, and that selection in shells is not necessary.
> But if twinning is suspected, as here, and/or a choice between high and low 
> symmetry spacegroup has to be made, one has to make sure that
> potentially symmetry-related reflections are _either_ labelled as test _or_ 
> as work; a mixture will artificially down-bias Rfree.
> 
> Selecting the test set in the highest possible symmetry (which is what Phenix 
> does) is a good solution. This test set should be symmetry-expanded when 
> trying the low-symmetry spacegroup (if one wants to compare R values). 
> The latter is not necessary when working with thin shells - but that has 
> other disadvantages.
> 
> best wishes,
> Kay
> 
> On Sun, 29 Aug 2021 14:32:34 +, Jon Cooper  
> wrote:
> 
>> Hello Engin, we discussed this a year or two ago in relation to NCS when Ian 
>> Tickle convinced me that since overfitting is due errors in the data, there 
>> is no reason to expect these errors to be correlated by NCS and picking the 
>> R-free set uniformally or in shells doesn't matter. No doubt my 
>> incompetence, but I can't see why twinning would be different.
>> 
>> Cheers, Jon.C.
>> 
>> Sent from ProtonMail mobile
>> 
>>  Original Message 
>> On 29 Aug 2021, 05:32, Engin Özkan wrote:
>> 
>>> Hi,
>>> 
>>> I believe this is taken care of automatically if you use phenix to pick
>>> your free reflections.
>>> 
>>> From http://www.phenix-online.org/documentation/tutorials/twinning.html
>>> 
>>> "When a test set is designed, care must be taken that free and work
>>> reflections are not related by a twin law. The R-free set assignment in
>>> phenix.refine and phenix.reflection_file_converter is designed with this
>>> in mind: the free reflections are chosen to obey the highest possible
>>> symmetry of the lattice."
>>> 
>>> I believe this applies to all datasets, just in case there may be twinning.
>>> 
>>> Engin
>>> 
> ...
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] How to process two datasets 45 degrees apart?

[Andrew Leslie - MRC LMB]

Dear Murpholino,

Assuming that the two datasets are from the same 
crystal, and collected without moving the crystal in-between, then when 
processing with mosflm I recommend processing both sweeps in the same mosflm 
run. This is because you will get more accurate cell parameters using data from 
both sweeps, due to the wider phi range.

Best wishes,

Andrew



> On 1 Jul 2021, at 00:57, Murpholino Peligro  wrote:
> 
> Hi...
> I have a couple of datasets:
> A: From 0 to 45
> B: From 90 to 135
> 
> Can I process them as a unique data set? (with XDS or maybe Mosflm) or should 
> I process them apart and then merge them? 
> 
> 
> Thanks
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] Ice ring data issue

[Andrew Leslie]

Apologies if this is a duplicate, not clear if the Email I sent 5 hours ago 
actually got sent.


Hi Alex,

 Although there is an “ice” icon in the imosflm GUI, which excludes 
all resolution bins where ice ringss are possible, this is not the best way to 
deal with this. Instead, use the Settings -> Processing options -> Processing 
tab, where you can specify individual resolution ranges to be excluded from the 
integration.

The important thing here is to make sure that the resolution range you specify 
is generous enough. Looking at an image and holding down the Ctrl key to give 
you the resolution where the mouse pointer is positioned, you need to make sure 
that you specify resolution limits that are a bit below (on the low resolution 
side) and above (on the high resolution side) the ice ring itself. This is 
because if any part of the measurement box extends into the ice ring it can 
affect the integration, and the measurement box is larger than the actual spot 
size.

This will, of course, affect your overall completeness, but it should get rid 
of the reflections with anomalous intensity. I find that the easiest way to 
check this is to look at the Wilson plot produced by ctruncate (one of the post 
you get when you run QuickScale).

Best wishes,

Andrew



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] Ice ring data issue

[Andrew Leslie]

Hi Alex,

 Although there is an “ice” icon in the imosflm GUI, which excludes 
all resolution bins where ice ringss are possible, this is not the best way to 
deal with this. Instead, use the Settings -> Processing options -> Processing 
tab, where you can specify individual resolution ranges to be excluded from the 
integration.

The important thing here is to make sure that the resolution range you specify 
is generous enough. Looking at an image and holding down the Ctrl key to give 
you the resolution where the mouse pointer is positioned, you need to make sure 
that you specify resolution limits that are a bit below (on the low resolution 
side) and above (on the high resolution side) the ice ring itself. This is 
because if any part of the measurement box extends into the ice ring it can 
affect the integration, and the measurement box is larger than the actual spot 
size.

This will, of course, affect your overall completeness, but it should get rid 
of the reflections with anomalous intensity. I find that the easiest way to 
check this is to look at the Wilson plot produced by ctruncate (one of the post 
you get when you run QuickScale).

Best wishes,

Andrew



> On 4 Mar 2021, at 15:39, Alexander Brown  
> wrote:
> 
> Hi all,
> I'm struggling with a dataset I have which shows very poor data quality 
> around 3.6A, or exactly where I can see a significant ice ring in the images. 
> I'm trying to use mosflm to process the image files, and I have seen a 
> previous thread on the message board where it is recommended to turn on three 
> tick boxes for ice ring exclusion, but despite this, as I continue through 
> the processing sequence and use aimless, it still flags that the data is 
> affected by an ice ring at that resolution, which you can also see in the 
> quality/resolution graphs. 
> 
> I have even tried making a mask in the moslfm viewer using the mask tool to 
> cover the entire ice ring, but to no avail.
> 
> Finally I did have a go at using EVAL which is mentioned in the original post 
> about ice rings, but it seems it depends on libgfortran3 packages which have 
> now been replaced with libgfortran5 and so I didn't get very far.
> 
> Is there a manual way to mask out certain data, or could there be something 
> with my data that is causing the automatic ice ring resolution not to be as 
> effective?
> 
> Thank you!
> 
> Alex Brown
> 
> PhD Student
> School of Pharmacy
> Biodiscovery Institute (previously Centre for Biomolecular sciences)
> University of Nottingham
> Nottingham
> NG7 2RD 
> 
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please contact the sender and delete the email and
> attachment. 
> 
> Any views or opinions expressed by the author of this email do not
> necessarily reflect the views of the University of Nottingham. Email
> communications with the University of Nottingham may be monitored 
> where permitted by law.
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] [EXTERNAL] Re: [ccp4bb] Modeling ATP/ADP

[Andrew Leslie]

Dear Reza,

  I would back Jon’s idea of looking at homologues, although 
this does depend on how close the homologue is. For example, if your protein 
has a “P” loop, with the Walker A sequence motif, then I think it would be very 
surprising if the nucleotide bound in different way to other P loop proteins. 
However, another objective way of fitting is to look at the stereochemical 
environment of the binding site. You might expect the phosphates to have 
several hydrogen bonds to the protein, very possibly involving basic side 
chains (Arg or Lys) and main chain amide groups. The adenine ring, on the other 
hand, typically sits in a more hydrophobic pocket, often with the adenine ring 
involved in a stacking interaction with a side chain.

The other objective test you can do is to try refining with different ways of 
modelling the nucleotide binding and see if the 2FoFc and difference maps look 
better for one binding mode than the others (and if the atomic B factors look 
more sensible). The phosphate groups are significantly more electron dense than 
the rest of the nucleotide. However if the density really is poor, it might be 
difficult to get an unambiguous answer, in which case you might have to rely on 
the stereochemical environment.

Good luck,

Andrew


> On 23 Jul 2020, at 18:12, Reza Khayat  wrote:
> 
> Tried the homologues thing. There are homologues and I've done the fitting, 
> but this is what I consider to be subjective. I'm certain the referee will 
> ask: Given the quality of density for the nucleotide, how certain are the 
> authors that a different fit is not possible? Have other fit poses been 
> considered?
> 
> Reza
> 
> Reza Khayat, PhD
> Assistant Professor 
> City College of New York
> Department of Chemistry and Biochemistry
> New York, NY 10031
> From: CCP4 bulletin board  on behalf of Jon Cooper 
> <488a26d62010-dmarc-requ...@jiscmail.ac.uk>
> Sent: Thursday, July 23, 2020 1:07 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [EXTERNAL] Re: [ccp4bb] Modeling ATP/ADP
>  
> Hello, do you have any homologues in the PDB with ATP, etc, bound as a guide? 
> Coot is pretty good at fitting known ligands, and unknown ones, too!
> 
> 
>  Original Message 
> On 23 Jul 2020, 17:53, Reza Khayat < rkha...@ccny.cuny.edu> wrote:
> 
> Hi,
> 
> Can folks suggest programs for objectively docking ATP/ADP molecules into 
> density? Our density is not so good, probably because of occupancy, and we'd 
> like a less subjecting approach for modeling. Thanks.
> 
> Best wishes,
> Reza
> 
> Reza Khayat, PhD
> Assistant Professor 
> City College of New York
> Department of Chemistry and Biochemistry
> New York, NY 10031
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] How many microfocus beamlines are in the world?

[Andrew Leslie]

Thanks for the clarification Dave, I completely agree that this is a very 
useful resource, but I can also understand why things are not always kept fully 
up-to-date.

Perhaps it would be useful if people notify the appropriate beam line team when 
they notice that the details on the Biosync website are out-of-date? I had not 
realised that the pages could be edited.

Best wishes,

Andrew


> On 27 Jun 2020, at 12:22, Hall, Dave (DLSLtd,RAL,LSCI) 
>  wrote:
> 
> Dear Andrew, Rasmus,
> 
> The pages are updated by the beamline teams typically. This is another set of 
> pages to keep up to date alongside their own websites (and others) so 
> sometimes can get overlooked when updates are made to beamlines or staff 
> change. However in spite of some out of date information they are a useful 
> set of webpages to get a snapshot in one place of beamlines across the world, 
> detector history and contact details, and for facility people the deposition 
> statistics pages are an incredibly useful tool for many reasons.
> 
> Best wishes
> 
> Dave
> 
> On 27/06/2020, 12:11, "CCP4 bulletin board on behalf of Andrew Leslie" 
>  wrote:
> 
>Dear Rasmus,
> 
>   Yes, I remember that the last time I looked at it 
> (which is probably 2 years ago) I also found beamlines where the details were 
> clearly not up-to-date. I see from the website that BioSync was funded by NIH 
> and NIGMS from 2016-2018, so maybe there is no funding to keep things up to 
> date, which is a pity.
> 
>Best wishes,
> 
>Andrew
>> On 27 Jun 2020, at 10:40, Rasmus Fogh  wrote:
>> 
>> Dear All,
>> 
>> The link http://biosync.rcsb.org/index.jsp looked very interesting, but a 
>> cursory look found the following line in a beamline description:
>> 
>> "Next proposal submission period Mid 2013"
>> 
>> Not 100% up to date, then.
>> 
>> Yours,
>> Rasmus
>> 
>> On 25/06/2020 09:36, Andrew Leslie wrote:
>>> Dear Morpholino,
>>> I think 10 microns or under is a reasonable way to define a micro focus 
>>> beam line. There is a list of all MX beamlines at the following web site:
>>> http://biosync.rcsb.org/index.jsp
>>> This gives details of each beam line, including beam size, but you would 
>>> have to go through them all to find the actual number. Also I’m not totally 
>>> sure how often this is updated.
>>> Best wishes,
>>> Andrew
>>>> On 24 Jun 2020, at 23:23, Murpholino Peligro >>> <mailto:murpholi...@gmail.com>> wrote:
>>>> 
>>>> That's a good point...
>>>> I was thinking that a decent crystal has a size in the hundreds of 
>>>> micrometers (say 100 in a, b and c). So, with such a specimen we can use 
>>>> any MX beamline.
>>>> But if the crystal is smaller (say 10 micrometers in a, b and c) You must 
>>>> use a microfocus beamline.
>>>> *Please correct me if I am wrong.*
>>>> So what are the number of MX beamlines that can get useful data from 
>>>> smaller crystals (as defined above)?
>>>> 
>>>> Thanks again
>>>> 
>>>> El mié., 24 de jun. de 2020 a la(s) 13:02, James Holton (jmhol...@lbl.gov 
>>>> <mailto:jmhol...@lbl.gov>) escribió:
>>>> 
>>>>   Define "micro focus" ?
>>>> 
>>>>   -James Holton
>>>>   MAD Scientist
>>>> 
>>>>   On 6/24/2020 9:18 AM, Murpholino Peligro wrote:
>>>>>   I would like to know how many MX beamlines are micro focus?
>>>>> 
>>>>> 
>>>>>   Thanks.
>>>>> 
>>>>>   
>>>>> 
>>>>>   To unsubscribe from the CCP4BB list, click the following link:
>>>>>   https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> To unsubscribe from the CCP4BB list, click the following link:
>>>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>>>> 
>>> 
>>> To unsubscribe from the CCP4BB list, click the following link:
>>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>> 
>> 
>> 
>> -- 
>> Rasmus H. Fogh   Tel.: +44 (0)1223 353033

Re: [ccp4bb] How many microfocus beamlines are in the world?

[Andrew Leslie]

Dear Rasmus,

   Yes, I remember that the last time I looked at it (which is 
probably 2 years ago) I also found beamlines where the details were clearly not 
up-to-date. I see from the website that BioSync was funded by NIH and NIGMS 
from 2016-2018, so maybe there is no funding to keep things up to date, which 
is a pity.

Best wishes,

Andrew
> On 27 Jun 2020, at 10:40, Rasmus Fogh  wrote:
> 
> Dear All,
> 
> The link http://biosync.rcsb.org/index.jsp looked very interesting, but a 
> cursory look found the following line in a beamline description:
> 
> "Next proposal submission period Mid 2013"
> 
> Not 100% up to date, then.
> 
> Yours,
> Rasmus
> 
> On 25/06/2020 09:36, Andrew Leslie wrote:
>> Dear Morpholino,
>> I think 10 microns or under is a reasonable way to define a micro focus beam 
>> line. There is a list of all MX beamlines at the following web site:
>> http://biosync.rcsb.org/index.jsp
>> This gives details of each beam line, including beam size, but you would 
>> have to go through them all to find the actual number. Also I’m not totally 
>> sure how often this is updated.
>> Best wishes,
>> Andrew
>>> On 24 Jun 2020, at 23:23, Murpholino Peligro >> <mailto:murpholi...@gmail.com>> wrote:
>>> 
>>> That's a good point...
>>> I was thinking that a decent crystal has a size in the hundreds of 
>>> micrometers (say 100 in a, b and c). So, with such a specimen we can use 
>>> any MX beamline.
>>> But if the crystal is smaller (say 10 micrometers in a, b and c) You must 
>>> use a microfocus beamline.
>>> *Please correct me if I am wrong.*
>>> So what are the number of MX beamlines that can get useful data from 
>>> smaller crystals (as defined above)?
>>> 
>>> Thanks again
>>> 
>>> El mié., 24 de jun. de 2020 a la(s) 13:02, James Holton (jmhol...@lbl.gov 
>>> <mailto:jmhol...@lbl.gov>) escribió:
>>> 
>>>Define "micro focus" ?
>>> 
>>>-James Holton
>>>MAD Scientist
>>> 
>>>On 6/24/2020 9:18 AM, Murpholino Peligro wrote:
>>>>I would like to know how many MX beamlines are micro focus?
>>>> 
>>>> 
>>>>Thanks.
>>>> 
>>>>
>>>> 
>>>>To unsubscribe from the CCP4BB list, click the following link:
>>>>https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> To unsubscribe from the CCP4BB list, click the following link:
>>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
>>> 
>> 
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> 
> 
> -- 
> Rasmus H. Fogh   Tel.: +44 (0)1223 353033
> Global Phasing Ltd., Fax.: +44 (0)1223 366889
> Sheraton House,
> Castle Park,
> Cambridge CB3 0AX
> United Kingdom
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] How many microfocus beamlines are in the world?

[Andrew Leslie]

Dear Morpholino,

I think 10 microns or under is a reasonable way to define a micro focus beam 
line. There is a list of all MX beamlines at the following web site:

http://biosync.rcsb.org/index.jsp 

This gives details of each beam line, including beam size, but you would have 
to go through them all to find the actual number. Also I’m not totally sure how 
often this is updated.

Best wishes,

Andrew

> On 24 Jun 2020, at 23:23, Murpholino Peligro  wrote:
> 
> That's a good point...
> I was thinking that a decent crystal has a size in the hundreds of 
> micrometers (say 100 in a, b and c). So, with such a specimen we can use any 
> MX beamline.
> But if the crystal is smaller (say 10 micrometers in a, b and c) You must use 
> a microfocus beamline. 
> *Please correct me if I am wrong.*
> So what are the number of MX beamlines that can get useful data from smaller 
> crystals (as defined above)?
> 
> Thanks again
> 
> El mié., 24 de jun. de 2020 a la(s) 13:02, James Holton (jmhol...@lbl.gov 
> ) escribió:
> Define "micro focus" ?
> 
> -James Holton
> MAD Scientist
> 
> On 6/24/2020 9:18 AM, Murpholino Peligro wrote:
>> I would like to know how many MX beamlines are micro focus?
>> 
>> 
>> Thanks.
>> 
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
>> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [ccp4bb] Overrefinement considerations and Refmac5.

[Andrew Leslie]

I would like to add a small caveat to Eleanor’s rule about a 3% difference 
being too low for a structure refined against 3Å data.

If the 3Å data is for a structure that has already been solved at much higher 
resolution (e.g. 2Å) and the only difference for the 3Å dataset is a different 
ligand (say) and the structure is solved by molecular replacement using the 
high resolution structure as a model, in those circumstances it is possible 
(and quite acceptable) to have a much lower difference between Rwork and Rfree 
than one might expect, even at low as 3-4%.


Andrew


> On 6 Mar 2020, at 15:22, Eleanor Dodson 
> <176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk> wrote:
> 
> You dont give the data resolution - that is very important..
> 
> I hate this rule bound approach to Rfree - R differences.. but as a guide
> No non-crystallographic symmetry.
> 1A data - you would expect them to be almost equal
> 3A data - I would expect a difference of at least 10% - once had the pleasure 
> of sendng a paper back as unreasonable when the data was only to 3A and the r 
> factors differed by 3% 
> 
> Pseudo-symmetry and non-crystallographic symmetry can make things more 
> complicated. 
> Ideally reflections related by such symmetry should match - either set belong 
> to the Rfree set, or working set.
> 
> The best way to get a low Rfactor and a high Rfree is to have virtually no 
> geometric restraints. ie have a very high weighting term.
> The auto selection works pretty well in my experience..
> 
> Not really an answer but some ideas..
> Eleanor
> 
> On Fri, 6 Mar 2020 at 13:32, M T  > wrote:
> Dear BBers,
> 
> I am trying to refine a structure using COOT and Refmac5 and I have some 
> concerns about overrefinement and x-ray term weight in Refmac5, based on the 
> fact that during refinement to let R factor to drift too far from Rfree is 
> not good...
> 
> So... First question about that : what is too far ? I have some values in 
> mind like 6% of difference is OK, 10% is not... But is there a relation in 
> between resolution of the structure and this difference? Should it be higher 
> at lower resolution, or always around 6-7% independently of the resolution?
> 
> Second question is, ok, I have a too big difference, lets say 9-10%... What 
> could be the reason of that and on what to play to reduce this difference?
> 
> One way I choose is to look at the x-ray term weight (even if I am totally 
> sure that Refmac5 is doing things better than me), because I saw that the 
> final rms on BondLength were to constraint (I have in mind that this value 
> should stays in between 0.02 and 0.01).
> So I looked into Refmac log to know where was the starting point and I found 
> 8.75.
> Then I tried several tests  and here are the results: 
> * 
> R factor
> Rfree
> BondLength
> BondAngle
> ChirVolume
> 
> Auto weighting and experimental sigmas boxes checked
> 0.1932
> 0.2886
> 0.0072
> 1.6426
> 0.1184
> 
> Weighting term at 4 and experimental sigmas box checked
> 0.1780
> 0.3159
> 0.1047
> 8.1929
> 0.5937
> 
> Weighting term at 4
> 0.1792
> 0.3143
> 0.1008
> 7.8200
> 0.5667
> 
> Weighting term at 15 and experimental sigmas box checked
> 0.1783
> 0.3272
> 0.2020
> 1.6569
> 0.9745
> 
> Weighting term at 15
> 0.1801
> 0.3279
> 0.2022
> 12.5748
> 0.9792
> 
> Weighting term at 8.75
> 0.1790
> 0.3235
> 0.1545
> 10.5118
> 0.7909
> 
> Auto weighting box checked
> 0.1948
> 0.2880
> 0.0076
> 1.6308
> 0.1176
> 
>  
> Refinement Parameters
> 
> 
> So like nothing looks satisfying I decided to ask my questions here...
> 
> What do you recommend to fix my problem, which is a too large difference 
> between R and Rfree?
> 
> Thank you for answers.
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] problems loading images in iMosflm under CCP4

[Andrew Leslie]

Dear Annette,

  Which version of iMosflm are you using? Version 7.2.2, 
that is currently distributed with the CCP4 suite, will not read Rigaku style 
Pilatus images (RIPI) correctly, you need version 7.3.0 that can be downloaded 
from the imosflm website:

https://www.mrc-lmb.cam.ac.uk/mosflm/imosflm/ver730/introduction.html 


Best wishes,

Andrew

> On 12 Feb 2020, at 00:50, Annette Herta Erbse  
> wrote:
> 
> Hi Everyone,
>  
> I apologize in advance I am probably doing something stupidly wrong, but I 
> have problems adding images taken with a Dectris Pilatus  200K detector  into 
> iMosflm. The files are .img files. I get the message “Error reading image 
> header. Message from Mosflm is Incorrect size of image for detector type 
> MAR”. But if I look at experiment settings detector it has recognized it as 
> RIPI Model 200K and under Experiment it has the beam position, the distance 
> and the wavelength right. So it is be able to read the header? I am confused 
> why it thinks it is a MAR detector image. 
>  
> Again I apologize if I am missing something obvious here.
> Best - Annette
>  
> Voice: ++1-303-492-0528 (office)
> Fax: ++1-303-492-8425
> Email:  er...@colorado.edu 
> Office: JSCB C316
>  
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Macromolecular Crystallography workshop in South America 2020

[Andrew Leslie]

Dear All,

  In fairness to the organisers, I would like to point out that 
there is nothing that is “lazy” about organising these workshops. It involves a 
considerable effort both in arranging the course, the venue and especially in 
attracting funds to support the workshop (it is important to note that CCP4 
does not supply all the funds). In addition, it is unfair to single out this 
particular workshop for criticism, as I believe it has long been the case that 
these workshops have not had a good gender balance in terms of the tutors. It 
is also important to realise that the gender imbalance does NOT extend to 
choice of the students, where as far as I am aware the gender balance is always 
very good.

One difficulty the organisers face is that funding will typically depend on 
having tutors with an international reputation in the areas in which they are 
teaching, ideally having been involved in developing the software that is being 
used. Unfortunately, this inevitably leads to gender bias.

While I would agree that this is an issue that is worthy of being raised, and I 
feel sure that this point will be taken on board by future organisers, it is 
also important to realise the practical difficulties that organisers face and 
the considerable effort that is involved in running these workshops.

Regards,

Andrew Leslie


> On 5 Feb 2020, at 00:30, Alejandro Buschiazzo  wrote:
> 
> Dear colleagues,
> 
> We are pleased to announce the 8th South American Macromolecular 
> Crystallography School: 
> 
> Macromolecular Crystallography School 2020 
> 
> "Structural Biology to enhance high impact research in health and disease”
> 
> 
> To be held at the Institut Pasteur de Montevideo (Uruguay) - September 9-19, 
> 2020
> 
> http://pasteur.uy/novedades/mx2020/ <http://pasteur.uy/novedades/mx2020/>
> 
> The application deadline is July 9, 2020. For further inquiries : 
> mx2...@pasteur.edu.uy <mailto:mx2...@pasteur.edu.uy>
> 
> 
> Main Topics:
> 
> ·   data processing;
> 
> ·   phasing and structure determination;
> 
> ·   model refinement and validation;
> 
> ·   introduction to crystallography + cryo-electron microscopy integration
> 
> 
> Confirmed speakers and tutors (so far... a few more will join the crew): 
> 
> 
> Alejandro Buschiazzo (Institut Pasteur de Montevideo, Uruguay)
> 
> Paul Emsley (Laboratory of Molecular Biology MRC, Cambridge, UK)
> 
> Rafael Junqueira Borges (Instituto de Biociências UNESP, Botucatu, Brazil)
> 
> Ronan Keegan (STFC Rutherford Appleton Lab - CCP4, Didcot, UK)
> 
> Eugene Krissinel (STFC Rutherford Appleton Lab - CCP4, Didcot, UK)
> 
> Joāo Muniz (Instituto de Fisica de São Carlos, Brazil)
> 
> Garib Murshudov (Laboratory of Molecular Biology MRC, Cambridge, UK)
> 
> Colin Palmer (STFC Rutherford Appleton Lab - CCP-EM, Didcot, UK)
> 
> James Parkhurst (Diamond Light Source, Didcot, UK)
> 
> Randy Read (University of Cambridge, UK)
> 
> Kyle Stevenson (STFC Rutherford Appleton Lab - CCP4, Didcot, UK)
> 
> Clemens Vonrhein (Global Phasing Ltd, Cambridge, UK)
> 
> 
> Please find the application form and further contact information at 
> http://pasteur.uy/novedades/mx2020/ <http://pasteur.uy/novedades/mx2020/> 
> (this www site will be updated regularly, so stay tuned!)
> 
> This Workshop is supported by the Collaborative Computational Project Nº4 
> (CCP4, UK) & Science and Technology Facilities Council (UK); the Centro de 
> Biologia Estructural del Mercosur (CeBEM); and the Programa Iberoamericano de 
> Ciencia y Tecnologia para el Desarrollo (CYTED) through de MICROBES 
> consortium.
> 
> Organizers:
> Alejandro Buschiazzo, PhD. Institut Pasteur de Montevideo, Uruguay
> Kyle Stevenson, DPhil. CCP4, STFC Rutherford Appleton Laboratory, United 
> Kingdom
> Richard Garratt, PhD. Instituto de Fisica de Sao Carlos, USP, Brazil
> 
> Applicants:
> 25 students will be selected, prioritizing advanced PhD, postdocs and young 
> researchers. The Course will provide financial support covering registration 
> fees, and for the case of those students coming from abroad, all local 
> expenses (lodging, per diem and local transportation). Look in the www site 
> for details on application procedures.
> 
> The application deadline is July 9, 2020.
> 
> Please address further inquiries to: mx2...@pasteur.edu.uy 
> <mailto:mx2...@pasteur.edu.uy>
> 
> Looking forward to hosting you in Montevideo!
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1 
> <https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Dates for the CCP4 Study Weekend on Refinement in 1980

[Andrew Leslie]

Hi Abhi,

Many thanks, that is very useful (in helping me fix the date for another event).

Best wishes,

Andrew
> On 24 Aug 2019, at 19:10, abhimanyu singh  wrote:
> 
> Hi Andrew,
> 
> A quick search showed that it took place between 15-16 November 1980 as 
> Proceedings of the Daresbury Study Weekend. I found this information on this 
> link: http://www.ccp4.ac.uk/html/sfall.html 
> <http://www.ccp4.ac.uk/html/sfall.html>. 
> 
> Regards,
> Abhi
> 
> On Sat, Aug 24, 2019 at 7:59 PM Andrew Leslie  <mailto:and...@mrc-lmb.cam.ac.uk>> wrote:
> An unusual request perhaps, but does anybody know the actual dates for the 
> 1980 CCP4 Study Weekend on Refinement?
> 
> I’m hoping that someone keeps better records than me (or is more proficient 
> at using Google)!
> 
> Thanks,
> 
> Andrew
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1 
> <https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1>
> 
> 
> -- 
> Abhimanyu Kumar Singh, PhD
> Post-doctoral Research Fellow
> Laboratory of Virology and Chemotherapy, Rega Institute for Medical Research
> Department of Microbiology and Immunology, KU Leuven
> Herestraat 49, box 1030, 3000 Leuven
> Belgium.
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1 
> <https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

[ccp4bb] Dates for the CCP4 Study Weekend on Refinement in 1980

[Andrew Leslie]

An unusual request perhaps, but does anybody know the actual dates for the 1980 
CCP4 Study Weekend on Refinement?

I’m hoping that someone keeps better records than me (or is more proficient at 
using Google)!

Thanks,

Andrew


To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

[ccp4bb] New release of iMosflm (version 7.3.0)

[Andrew Leslie]

A new release (version 7.3.0) of the data processing program iMosflm is now 
available for the MRC website:
https://www.mrc-lmb.cam.ac.uk/mosflm/imosflm 
<https://www.mrc-lmb.cam.ac.uk/mosflm/imosflm>

The most significant difference to the previous version (7.2.2) is the ability 
to read Dectris HDF5 files directly, rather than having to convert them to CBF 
files (using eiger2cbf). These changes were implemented by Harry Powell (now an 
independent software consultant) with financial support from Dectris, Diamond 
Light Source and CCP4. When reading HDF5 files, there is the option to sum 
images prior to processing, which may give improved performance if the 
oscillation angle is very small. 

Images from the new Dectris Eiger2 and Dectris Quadro detectors and Rigaku 
Pilatus and Eiger image formats are also handled.

A bug in version 7.2.2 meant that MTZ files produced when using the multi 
lattice integration option could not be read correctly by any downstream 
programs (POINTLESS etc). this has been corrected. There have also been minor 
changes to the integration of very weak images (where many pixel values are 
zero) to avoid bias in the intensity estimation.

There have been numerous additional minor improvements and bug fixes, a full 
list is given on the web site (Under “changes since 7.2.2").

The reading of HDF5 format images has been tested with files from ESRF and 
Diamond Light Source. Because there is not yet a universally agreed format for 
the header information, there may be issues with reading the metadata (phi 
values, detector distance, wavelength etc) from files produced elsewhere, 
please let me know if this is the case.

This latest version will be released as part of the CCP4 package in due course.

Andrew Leslie


To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Error in data reduction!

[Andrew Leslie]

Dear Mike and Helen,

As I understand it, the XML is only written when POINTLESS/AIMLESS are run 
through the CCP4 GUI and the command comes from the GUI script, so there is no 
way you can turn this off from POINTLESS itself. 

However, if you use the “Run com file” option from CCP4i GUI, you will see 
the XMLOUT command there (see attached figure). If you delete this (for both 
POINTLESS and AIMLESS and CTRUNCATE) then the jobs will run and produce an MTZ 
file, but it did give a "job failed" message:

#CCP4I TERMINATION STATUS 0 Error from script 
/Applications/ccp4-7.0/share/ccp4i/scripts/aimless.script: couldn't open 
"/Users/andrew/g4/MOSFLM/camillo/camillo_1_pointless.xml": no such file or 
directory

However the MTZ file was there.

Did your job produce a final  MTZ file in spite of the warning?

I’m afraid I don’t understand why the XML file was not written in your case, 
are you sure the path shown in the “Command Line” output from the GUI is OK for 
writing to?

Best wishes,

Andrew



> On 11 Jul 2019, at 13:34, Helen Ginn  wrote:
> 
> Dear Mike,
> 
> No problem! Happy to provide suggestions, though I'd prefer to be addressed 
> directly on here.
> 
> Here's another suggestion, no promises. If you can provide more detail on the 
> GUI input and the output log files, it would be easier to know why this is 
> happening in the first place. However, you can also click and hold "Run" in 
> ccp4i and select "Run Com File". Then you will receive each program's 
> command line input and you can edit them before you run them. I suggest 
> removing or correcting any instances of `XMLOUT `.  
> 
> Thanks Andrew for confirming with Phil on the behaviour of pointless. I have 
> looked at the ccp4i interface and cannot find any option for enabling XML 
> output for pointless in the Symmetry/scale/merge pipeline. The option to 
> output to XML in the standalone pointless does not seem to transfer this to 
> the command line options, but Mike is probably using the former GUI input 
> window anyway. As such I'm not sure where the XMLOUT command is coming from.
> 
> Best wishes
> Helen
> 
>> Dear Andrew,
>> 
>> Thanks for your suggestion. Yes, you are right that the error is because 
>> .xml file is not being written. but not able to find the reasons...I 
>> checked...Disk space is free and have permission to write also. I could able 
>> to run Pointless, but not Aimless. 
>> 
>> Any other reason??
>> 
>> Thanks
>> 
>> Mike
>> 
>> On Wed, Jul 10, 2019 at 5:37 PM Andrew Leslie <[log in to unmask]> wrote:
>> 
>>   I think Helen’s answer is absolutely right. I asked Phil Evans about this 
>> when I saw him yesterday, and he said that error usually arises when it is 
>> not possible to write the xml file, either because a disk is full, or 
>> because you do not have permission to write to that area.
>> 
>>   Andrew
>> 
>>>   On 3 Jul 2019, at 15:09, Mike Xishan <[log in to unmask]> wrote:
>>> 
>>>   Dear all,
>>> 
>>>   Sorry for asking for a very naive question that might be asked before.
>>> 
>>>   After integration, I am trying to do "data reduction" through Aimless, 
>>> but task fails with an error message as
>>> 
>>>   #CCP4I TERMINATION STATUS 0 "FILEIO: cannot open file 
>>> /Processing1_8_pointless.xml
>>> 
>>>   I really appreciate for your opinion and help to fix this problem.
>>> 
>>>   Thanks, 
>>> 
>>>   Mike
>>> 
>>> 
>>>   To unsubscribe from the CCP4BB list, click the following link:
>>>   https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>> 
>> 
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
>> 




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Error in data reduction!

[Andrew Leslie]

I think Helen’s answer is absolutely right. I asked Phil Evans about this when 
I saw him yesterday, and he said that error usually arises when it is not 
possible to write the xml file, either because a disk is full, or because you 
do not have permission to write to that area.

Andrew

> On 3 Jul 2019, at 15:09, Mike Xishan  wrote:
> 
> Dear all,
> 
> Sorry for asking for a very naive question that might be asked before. 
> 
> After integration, I am trying to do "data reduction" through Aimless, but 
> task fails with an error message as
> 
>  #CCP4I TERMINATION STATUS 0 "FILEIO: cannot open file 
> /Processing1_8_pointless.xml
> 
> I really appreciate for your opinion and help to fix this problem.
> 
> Thanks, 
> 
> Mike
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

[ccp4bb] X-ray equipment available

[Andrew Leslie]

We have a Rigaku Actor robot and a HTC Image plate detector that we no longer 
require. Both are ten years old. If anyone is interested in acquiring these for 
a nominal sum (plus shipping costs) please let me know.

Andrew Leslie
MRC LMB, Cambridge


To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Off topic: 'Difficult' Datasets for Processing Practice

[Andrew Leslie]

Dear Matthew,

   I am also late in responding to this, but as part of a 
Nature Protocols paper on iMosflm (Supplementary Information for Nature 
Protocols 12, 1310-1325, 2017) I provided a number of examples of “problem 
datasets”. Some of these are just two images, to show issues in indexing, 
others are complete datasets showing a variety of pathologies.

All the images and a tutorial on how best to process them (with iMosflm) are 
available at the following URL:

www.mrc-lmb.cam.ac.uk/harry/imosflm/examples 



Best wishes,

Andrew


> On 26 Sep 2018, at 03:15, Whitley, Matthew J  wrote:
> 
> For some reason, the September 19th ccp4bb digest got caught in my spam 
> filter and didn't come through until a few minutes ago, so I didn't see 
> several responses concerning interesting datasets for processing until just 
> now.
> 
> Therefore, thanks also to Kay Diederichs, Eugene Osipov, and David Waterman 
> for responding (and also to everyone else who responded if I am still 
> overlooking anyone.)
> 
> As I mentioned before, I will be happy to compile a list of suggested 
> datasets and make it available via this list.
> 
> Matthew
> 
>  ---
> Matthew J. Whitley, Ph.D.
> Research Instructor
> Department of Pharmacology & Chemical Biology
> University of Pittsburgh School of Medicine
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1 
> 



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] [EXTERNAL] Re: identifying bound ions

[Andrew Leslie]

Hi Herman,

  We can run it stand alone, (i.e. "which xpand” points to an 
exe that runs) but we have the Uppsala suite installed on our machine.

Cheers,

Andrew

> On 2 Aug 2018, at 07:38, herman.schreu...@sanofi.com wrote:
> 
> Dear Kay,
> 
> I have looked at XPAND and it looks like it is part of the O-package. Do you 
> know if it can also be used stand-alone?
> 
> Best,
> Herman 
> 
> -Ursprüngliche Nachricht-
> Von: Kay Diederichs [mailto:kay.diederi...@uni-konstanz.de] 
> Gesendet: Mittwoch, 1. August 2018 15:00
> An: CCP4BB@JISCMAIL.AC.UK; Schreuder, Herman /DE
> Betreff: [EXTERNAL] Re: identifying bound ions
> 
> Dear Herman,
> 
> the "water scrutinizer" option of XPAND does this -. 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.msg.ucsf.edu_local_programs_ono_manuals_xpand-5Fman.html-23S7=DwIFaQ=Dbf9zoswcQ-CRvvI7VX5j3HvibIuT3ZiarcKl5qtMPo=HK-CY_tL8CLLA93vdywyu3qI70R4H8oHzZyRHMQu1AQ=xDNvO2p9KWi88plMQdKeBus0tAym2doLwUPdQNfYRG8=sEx3IqjhUIdjbiqizdljtA1eTlNHUhuaNKMHipOp6L4=
>  
> 
> best wishes,
> 
> Kay
> 
> On Tue, 31 Jul 2018 12:39:01 +, herman.schreu...@sanofi.com wrote:
> 
>> Dear BB,
>> 
>> I know it has been discussed some time ago, but a google search did not come 
>> up with anything useful.
>> 
>> I need a program which analyzes the bound waters and suggests whether a 
>> particular water might be a chloride, calcium, sulfate, sodium or something 
>> else. Preferably a program that can be run off-line (not a web server), but 
>> if there is no choice, we will use a webserver as well.
>> 
>> Thank you for your suggestions!
>> Herman
>> 
>> 
>> 
>> 
>> 
>> 
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jiscmail.ac.uk_cgi-2Dbin_webadmin-3FSUBED1-3DCCP4BB-26A-3D1=DwIFaQ=Dbf9zoswcQ-CRvvI7VX5j3HvibIuT3ZiarcKl5qtMPo=HK-CY_tL8CLLA93vdywyu3qI70R4H8oHzZyRHMQu1AQ=xDNvO2p9KWi88plMQdKeBus0tAym2doLwUPdQNfYRG8=7Fy9spg-ZpKgzdg0fT25uD-PzjkXI5bt48_hAD-zTSo=
>>  
>> 
> 
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] Resolution mismatch aimless/refmac

[Andrew Leslie]

Hi Orru,

   If you have used the normal CCP4 processing pipeline, the data from 
AIMLESS will go into the “uniqueifyy” script that adds all possible reflections 
to the MTZ file (down to the lowest possible resolution for your unit cell 
dimensions), so that might explain why the low resolution limit has changed to 
67Å. In  AIMLESS, it will be the low resolution limit set by the integration 
program.

Cheers,

Andrew

> On 18 Mar 2018, at 10:46, Orru, Dr. Roberto  wrote:
> 
> Dear All,
> 
> I am noticing that the low resolution in the reflections files after scaling 
> with aimless and after refinement with refmac does not coincide.
> In a case I have 37A with aimless but for some reason refmac is 67A.
> 
> Any idea?
> All the best,
> R.

[ccp4bb] New release of iMosflm (7.2.2)

[Andrew Leslie]

There is a new release of iMosflm available from the MRC-LMB web site:  
https://www.mrc-lmb.cam.ac.uk/harry/imosflm/ 
<https://www.mrc-lmb.cam.ac.uk/harry/imosflm/>

The changes since the previous version are listed below, perhaps the most 
important is that this version will read the “full cbf” image format produced 
on beam lines IO4 and IO3 (and other beamlines in the near future) at the 
Diamond Light Source.

Please notify mos...@mrc-lmb.cam.ac.uk <mailto:mos...@mrc-lmb.cam.ac.uk> of any 
issues with this version.

Andrew Leslie & Harry Powell
Allow reading new-style Pilatus full CBF images written at Diamond Light Source 
(currently on beamlines IO4 and IO3 but soon to be extended to other 
beamlines). Version 7.2.1 will NOT read these images.

Correct a bug introduced in version 7.2.1 that caused detector parameter 
refinement to fail if detector parameters that were previously fixed were 
subsequently allowed to refine.

Deal optimally with Pilatus detectors where pixels in the gaps between modules 
have been assigned a value of zero rather than -1 (the default).

Check to make sure duplicate image numbers cannot be given to Integration task.

XML output being provided for CCP4i2 from both QuickScale and QuickSymm tasks.

Replaced pop-up that gave advice on how to proceed after indexing failure with 
one that gives option widgets and somewhat clearer advice.

Always set the pixel size from the current session; occasionally previous 
versions retained the pixel size from previous sessions (when using the "New 
session" option) which caused problems if the detector changed.

Metadata from Rigaku Pilatus detectors handled better (crystal to detector 
distance and detector two-theta angle were decoded incorrectly).

Small change in treatment for image data from Rigaku Pilatus detectors (default 
value for gain changed).

 Improved reading of metadata from Ed Westbrook's Taurus detector.

 Many output statements modified to help ensure valid XML is supplied to 
iMosflm.

 Tile boundaries correctly specified for Pilatus 2M.

Improve spot-finding near tile boundaries and shadows by reducing default size 
of local background box to 10 pixels and increasing the size of the safety zone 
(excluded from spot finding) adjacent to tile boundaries and defined masked 
areas.

Use the "count_cutoff" value from image header to set the detector saturation 
value for Pilatus and Eiger detectors.

Automatically set the "reverse phi" flag for detectors at Spring-8, recognised 
by the detector serial number.

Re: [ccp4bb] double cell dimensions between P2 and C2

[Andrew Leslie]

Dear Markus,

 I have seen something similar before, I think it was only 
one cell dimension that was changing (and not the lattice type), but it could 
double or triple the cell edge, crystals grown in very similar conditions, 
impossible to tell from morphology what the cell would be, so such things can 
happen.

Cheers,

Andrew
> On 9 Nov 2017, at 10:02, Markus Heckmann  wrote:
> 
> Dear all,
>> From a small protein, gives crystals P2 with cell
> Cell 53.16   65.73   72.8990  110.94  90
> (has 3 molecules in the asymmetric unit). Tested with pointless. Does
> not give any other possibility.
> 
> Another crystal if the same protein, similar conditions:
> C2
> Cell 109.14  124.37   73.4290  111.75  90. This has 6
> molecules in the a.s.u. Tested with pointless. Does not give any other
> possibility.
> The cell length a, b of C2 is twice that of P2.
> 
> Is it usual to get such crystals from similar conditions or am I
> missing something?
> 
> Many thanks,
> Mark

Re: [ccp4bb] doubt regarding MR search model

[Andrew Leslie]

Regarding the warning message "The top solution from a TF rescoring did not 
pack”, I get this on all the PHASER jobs that I have run recently, but looking 
through the PHASER log file I cannot see any evidence for packing failure.

It may be that the failure is buried in an obscure place in the very long log 
file, but if I search for “pack” then I get the output summarised below, all of 
which, apart from the ADVISORY, suggests to me that there is no problem at all 
with the packing.

Perhaps someone on the PHASER team can cast light on this.

Andrew


Extracts from PHASER log file:


TRANSLATION FUNCTIONS
-

   Target Function: FAST LETF1
   Translation Packing Function applied: top peak will pack
   Translation Packing Cutoff: 50%
   Sampling:  1.82 Angstroms


===

PACKING FUNCTION


   There are 4 solutions to pack
   Packing analysis
   0%100%
   |=| DONE


   Packing Table
   -
   Solutions accepted if pairwise clashes less than 10 % of trace atoms
   #in  #out Clash-% Symm TF-SET  ROT TFpk#TFTFZSpaceGroup 
   1Top1  0.741  --   1 11325.94 26.03  P 1
   22 1.058  --   1 21293.29 24.34  P 1
   33 0.952  --   1 31245.70 21.88  P 1
   44 0.847  --   1 41211.49 20.11  P 1

   4 accepted of 4 solutions
  4 pack of 4 accepted solutions

==
---
TRANSLATION PACKING
---

   Translation Packing Cutoff: 50%
   All solutions have been packed

==
   Packing Fast Search Translations...
  9871 peaks
  500 peaks over 1049.74 checked for packing
  Translation peak 1 first to be kept
  Done


   New Top Packing Fast Translation Function FSS = 2181.37 (TFZ=46.3) at Trial 
#1


   Top Peaks Without Clustering
   Select peaks over 67.5% of top (i.e. 0.675*(top-mean)+mean)
   There was 1 site over 67.5% of top
   1 peak selected
   The sites over 67.5% are:
   # Frac X Frac Y Frac ZFSS   Z-score
   1  0.719  0.122  0.890 2181.4 46.35

   Top 1 translations before clustering will be rescored
   Calculating Likelihood for TF SET #1 of 1 TRIAL #1 of 1
   0% 100%
   |==| DONE

   Packing LLG Translations: pass 1 of 11...
  1 peaks
  No peaks over 1878.46 - no packing check
   Packing LLG Translations: pass 2 of 11...
  1 peaks
  1 peaks over 1878.46 checked for packing
  Translation peak 1 first to be kept
  Done
  Exit: found a peak that packs

-==

*** AND THEN ***
--
Advisory: The top solution from a TF rescoring did not pack
--


-==
-

> On 18 Sep 2017, at 15:06, Eleanor Dodson  wrote:
> 
> You need to provide a bit more information.
> 
> First of all about the data processing..
> 
> Is the space group correct?
> ways of being misled are:
> Non-crystallographic translations with a shift of ~0.5 along an axis - say a. 
>  This will generate absences in the odd h 0 0 reflections and can make the 
> space group appear to be P 21 21 21 whilst it is really P 2 21 21..
> 
> Perfect twinning can have the same effect. In an orthorhombix space group 
> this can usually only occur if two axes have approximately the same length, 
> but the data processing stats can indicate if that is the case.
> 
> Then - re PHASER. The packing rejection criteria may be set too severely - 
> that seems the case for your solution.
> 
> Best check on any MR solution is: does it refine - give it 20 cycles of 
> mindless refinement and see if the R and FreeR go down.
> 
> Then look at the maps and see if there are obvious corrections to be made..
> 
> Eleanor
> 
> On 18 September 2017 at 14:59, Satvik Kumar  > wrote:
> Dear Crystallographers,
> 
> I am trying to solve a structure in the space group P212121. Based on 
> Matthews coefficient, there are 4 molecules in the asymmetric unit.
> 
> Based on my limited reading about using of Phaser, I understand that a single 
> chain should be used as search model even though many copies are present in 
> asymmetric unit. Am I correct?
> 
> So when I use a single chain as search model and ask Phaser to search for 4 
> molecules, Phaser identifies a single solution with a warning "The top 
> solution from a TF rescoring did not pack" and a warning "Search request 
> requires more scattering than defined in composition. Composition increased 
> to accommodate search components". But the final values 

Re: [ccp4bb] "reset" a structure before re-refinement

[Andrew Leslie]

Hi Graeme,

You can do this with PDBSET, keyword NOISE
Cheers,


Andrew

> On 17 Aug 2017, at 16:17, Graeme Winter  wrote:
> 
> Dear All,
> 
> Is there a protocol out there to gently perturb atomic positions so that 
> re-running refinement can essentially put them back without bias from the 
> original refinement? In particular, if trying to perform the Karplus and 
> Diederichs paired refinement protocol, I do not want to run the lower 
> resolution refinements with the "memory" of the weak high resolution data 
> present... and only have the refined structure to work from...
> 
> Am using refmac5, but any pdb randomizer would hit the spot
> 
> Many thanks Graeme
> 
> -- 
> This e-mail and any attachments may contain confidential, copyright and or 
> privileged material, and are for the use of the intended addressee only. If 
> you are not the intended addressee or an authorised recipient of the 
> addressee please notify us of receipt by returning the e-mail and do not use, 
> copy, retain, distribute or disclose the information in or attached to the 
> e-mail.
> Any opinions expressed within this e-mail are those of the individual and not 
> necessarily of Diamond Light Source Ltd. 
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any 
> attachments are free from viruses and we cannot accept liability for any 
> damage which you may sustain as a result of software viruses which may be 
> transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and 
> Wales with its registered office at Diamond House, Harwell Science and 
> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Re: [ccp4bb] Indexing question

[Andrew Leslie]

Dear Grace,

 There are two ways that you can do this. If you run 
POINTLESS/AIMLESS from iMosflm using the “Quickscale” option, you can tell 
POINTLESS to use the symmetry set at the indexing stage, using SETTINGS -> 
Processing options -> Sort Scale and Merge tab,, select the tick box “ Use 
iMosflm symmetry in Quickscale option”. So providing the C2 space group is 
selected at the indexing stage, it will keep that symmetry.

If running POINTLESS/AIMLESS through CCP4i, in the Data reduction - Pointless, 
Aimless, Ctruncate window, under the “Options for Pointless” box you can select 
an option:
Set primitive orthorhombic groups in cell length order (a<b<c) but always use 
C2 rather than I2”.

Either way should work!

Best wishes,

Andrew

> On 18 Jul 2017, at 20:17, Grace Beggs <grace.be...@duke.edu> wrote:
> 
> Thank you, Andrew. How do I tell POINTLESS to keep C2?
> 
> Grace
> 
> 
> Grace Beggs
> Brennan lab
> Department of Biochemistry | Duke University
> Email: grace.be...@duke.edu <mailto:grace.be...@duke.edu>
> 
> 
> From: Andrew Leslie <and...@mrc-lmb.cam.ac.uk 
> <mailto:and...@mrc-lmb.cam.ac.uk>>
> Sent: Tuesday, July 18, 2017 1:48:23 PM
> To: Grace Beggs; c...@ccp4.ac.uk <mailto:c...@ccp4.ac.uk> Laboratory
> Subject: Re: Indexing question
>  
> Dear Grace,
> 
>  POINTLESS will convert a C2 cell into I2 if this results a 
> beta angle closer to 90, so that the axes are closer to being orthogonal. All 
> CCP4 programs should work with I2, so this should not cause any issues. If 
> you want to keep the C@ space group, you can tell POINTLESS to keep C2 rather 
> than changing to I2.
> 
> Best wishes,
> 
> Andrew
> 
>> On 18 Jul 2017, at 18:42, Grace Beggs <grace.be...@duke.edu 
>> <mailto:grace.be...@duke.edu>> wrote:
>> 
>> To whom it may concern:
>> 
>> I am using version 7.2.1 of iMosflm. I have indexed, refined and 
>> successfully integrated and scaled my data with the space group C 1 2 1. 
>> Although the log file output after running aimless states the space group as 
>> C 1 2 1, when I load the mtz file into Phenix it states the space group is I 
>> 1 2 1. Could imosflm be writing the mtz file as I 1 2 1? How does one 
>> correct this? I 1 2 1 is not a standard space group.
>> 
>> Thank you,
>> Grace Beggs
>> 
>> 
>> Grace Beggs
>> Brennan lab
>> Department of Biochemistry | Duke University
>> Email: grace.be...@duke.edu <mailto:grace.be...@duke.edu>

Re: [ccp4bb] Rmergicide Through Programming

[Andrew Leslie]

I would like to support Graeme in his wish to retain Rmerge in Table 1, 
essentially for exactly the same reasons. 

I also strongly support Francis Reyes comment about the usefulness of Rmerge at 
low resolution, and I would add to his list that it can also, in some 
circumstances, be more indicative of the wrong choice of symmetry (too high) 
than the statistics that come from POINTLESS (excellent though that program 
is!).

Andrew
> On 5 Jul 2017, at 05:44, Graeme Winter  wrote:
> 
> HI Jacob
> 
> Yes, I got this - and I appreciate the benefit of Rmeas for dealing with 
> measuring agreement for small-multiplicity observations. Having this *as 
> well* is very useful and I agree Rmeas / Rpim / CC-half should be the primary 
> “quality” statistics.
> 
> However, you asked if there is any reason to *keep* rather than *eliminate* 
> Rmerge, and I offered one :o)
> 
> I do not see what harm there is reporting Rmerge, even if it is just used in 
> the inner shell or just used to capture a flavour of the data set overall. I 
> also appreciate that Rmeas converges to the same value for large multiplicity 
> i.e.:
> 
>Overall  InnerShell  OuterShell
> Low resolution limit   39.02 39.02  1.39
> High resolution limit   1.35  6.04  1.35
> 
> Rmerge  (within I+/I-) 0.080 0.057 2.871
> Rmerge  (all I+ and I-)0.081 0.059 2.922
> Rmeas (within I+/I-)   0.081 0.058 2.940
> Rmeas (all I+ & I-)0.082 0.059 2.958
> Rpim (within I+/I-)0.013 0.009 0.628
> Rpim (all I+ & I-) 0.009 0.007 0.453
> Rmerge in top intensity bin0.050- - 
> Total number of observations 1265512 16212 53490
> Total number unique17515   224  1280
> Mean((I)/sd(I)) 29.7 104.3   1.5
> Mn(I) half-set correlation CC(1/2) 1.000 1.000 0.778
> Completeness   100.0  99.7 100.0
> Multiplicity72.3  72.4  41.8
> 
> Anomalous completeness 100.0 100.0 100.0
> Anomalous multiplicity  37.2  42.7  21.0
> DelAnom correlation between half-sets  0.497 0.766-0.026
> Mid-Slope of Anom Normal Probability   1.039   - -  
> 
> (this is a good case for Rpim & CC-half as resolution limit criteria)
> 
> If the statistics you want to use are there & some others also, what is the 
> pressure to remove them? Surely we want to educate on how best to interpret 
> the entire table above to get a fuller picture of the overall quality of the 
> data? My 0th-order request would be to publish the three shells as above ;o)
> 
> Cheers Graeme
> 
> 
> 
>> On 4 Jul 2017, at 22:09, Keller, Jacob > > wrote:
>> 
>> I suggested replacing Rmerge/sym/cryst with Rmeas, not Rpim. Rmeas is simply 
>> (Rmerge * sqrt(n/n-1)) where n is the number of measurements of that 
>> reflection. It's merely a way of correcting for the multiplicity-related 
>> artifact of Rmerge, which is becoming even more of a problem with data sets 
>> of increasing variability in multiplicity. Consider the case of comparing a 
>> data set with a multiplicity of 2 versus one of 100: equivalent data quality 
>> would yield Rmerges diverging by a factor of ~1.4. But this has all been 
>> covered before in several papers. It can be and is reported in resolution 
>> bins, so can used exactly as you say. So, why not "disappear" Rmerge from 
>> the software?
>> 
>> The only reason I could come up with for keeping it is historical reasons or 
>> comparisons to previous datasets, but anyway those comparisons would be 
>> confounded by variabities in multiplicity and a hundred other things, so 
>> come on, developers, just comment it out!
>> 
>> JPK
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: graeme.win...@diamond.ac.uk  
>> [mailto:graeme.win...@diamond.ac.uk ] 
>> Sent: Tuesday, July 04, 2017 4:37 PM
>> To: Keller, Jacob > >
>> Cc: ccp4bb@jiscmail.ac.uk 
>> Subject: Re: [ccp4bb] Rmergicide Through Programming
>> 
>> HI Jacob
>> 
>> Unbiased estimate of the true unmerged I/sig(I) of your data (I find this 
>> particularly useful at low resolution) i.e. if your inner shell Rmerge is 
>> 10% your data agree very poorly; if 2% says your data agree very well 
>> provided you have sensible multiplicity… obviously depends on sensible 
>> interpretation. Rpim hides this (though tells you more about the quality of 
>> 

Re: [ccp4bb] peroxy-glutamate?

[Andrew Leslie]

Dear Ed,

  I find your electron density quite interesting, because generally 
(I think, I would be happy to be corrected on this) when de-carboxylation of 
Asp/Glu occurs due to radiation damage, there is no evidence of what happens to 
the resulting CO2 group. One interpretation of this is that it diffuses away 
from the side chain and is effectively totally disordered, so no electron 
density is seen, but I was surprised that this would always be the case, 
especially as I would have thought that diffusion would be quite limited at 
100K (maybe I’m wrong about that too, but that is supposed to be one reason why 
radiation damage is less at 100K).

If the residual density is due to partial de-carboxylation, then I would have 
expected density for the CG-CD bond, which is not present (at your chosen 
contour level).

Do many of your Glu side chains have the residual density?

Best wishes,

Andrew


> On 3 May 2017, at 22:19, Edward A. Berry  wrote:
> 
> 
> 
> On 05/03/2017 02:46 PM, Gerard Bricogne wrote:
>> Dear Ed,
>> 
>>  Have you considered the possibility that it could be a water
>> stepping in to fill the void created by partial decarboxylation of the
>> glutamate? That could be easily modelled, refined, and tested for its
>> ability to flatten the difference map.
>> 
>>  Gerard.
>> 
> Actually some of them do appear decarboxylated. Is that something that can 
> happen? In the crystal, or as radiation damage?
> However when there is density for the carboxylate (figure), it appears 
> continuous and linear, doesn't break up into spheres at H-bonding distance - 
> almost like the CO2 is still sitting there- but I guess it would get hydrated 
> to bicarbonate. I could use azide. Or maybe waters with some disorder.
> Thanks,
> eab
> 
> Figure- 2mFo-DFc at 1.3 sigma, mFo-DFc at 3 sigma, green CO2 is shown for 
> comparison, not part of the model.
> 
> 

Re: [ccp4bb] large number in ASU

[Andrew Leslie]

Dear Jademilson,

At a CCP4 APS workshop a few years ago, one of the 
students solved a molecular replacement problem where I think there were close 
to 40 copies in the asu. I have to say that many people were surprised by this, 
but I think the protein was smaller and they had a very good search model - I 
can’t remember the resolution of the data.  The job certainly ran for a long 
time (overnight I think), but it does show that in some circumstances this can 
work. Possibly Randy Ready can remember the details better than I do. However 
in your case you may need to resort to experimental phasing.

Good luck!

Andrew


> On 26 Apr 2017, at 20:34, Jademilson Santos  
> wrote:
> 
> Greetings all,
> 
> I am having trouble with a data set and would like to know if somebody can 
> help. I'm working with a protein of approximately 50 kDa, which I have 
> successfully crystallized. The crystals diffracted at a resolution of 3,65 
> angstroms and upon initial processing using XDS i obtained the following 
> information: 
> 
> space group: P21
> ISA = 33.3
> cell unit: a=285.2, b=135.9, c= 287.5, α=90, β=117.5, γ=90
> 
> Matthews coefficient indicates that there are 40 molecules in the asymmetric 
> unit 
> 
> I am currently running the program Phaser (Phenix) to determine the phase via 
> molecular replacement with a model that has 49% homology and query coverage 
> of 94% and the program is taking extremly long to finish. In this case in 
> which there is an extremly high number of molecules in the asymmetric unit, 
> is this actually possible? Does someone know how to work with these values 
> and is there a specific strategy which i must follow?
> 
> Regards
> 
> Jademilson Celestino dos Santos
> 
> Laboratory of Applied Structural Biology
> Department of Microbiology
> Institute of Biomedical Sciences
> University of São Paulo- USP

Re: [ccp4bb] Why aren't green reflections on Mosflm integrated?

[Andrew Leslie]

Dear Walt,

 As Tim has said, this is indeed related to the Lorentz 
correction. These reflections have a large Lorentz correction which is also 
very sensitive to the crystal orientation, so any small error in orientation 
can result in a big change to the Lorentz correction and thus to the corrected 
intensity. However, the default maximum reflection width can be changed 
(Experiment settings, Advanced Integration) and sometimes this is necessary to 
avoid excluding too many reflections in cases where the mosaic spread is very 
high (> 1° say) or the mosaic block size is small.

I think this feature is common to all integration programs, although the 
default settings may well be different.

Best wishes,

Andrew
On 14 Dec 2016, at 01:40, Hank  wrote:

> Dear CCP4BB users,
> 
> I have a question about Mosflm. The manual says green predictions have
> "reflection width greater than 5 degrees" and will not be integrated. I always
> assumed it should have something to do with Lorentz factor but not quite sure.
> Why is it so? I'm not aware of such geometrical restriction in HKL2000.
> Thank you!
> 
> Walt

Re: [ccp4bb] mtz format problem from iMosflm

[Andrew Leslie]

Dear Tom,

 I believe that I once had a similar problem and if I remember correctly (and 
I'm not certain about this) it was caused by having an extremely large negative 
intensity (rather than +ve), which could be why the scaling steps did not work 
because they might only look at +ve values, not -ve ones (I'm not certain about 
this either).

If the suggestions Harry made do not help, one way that you could check this is 
to grep the mosflm log file for the string: Minimum Intensity= (or 
alternatively, grep for Maximum Intensity= to look for a very large +ve 
value.)

Could I also ask what version of ipmosflm you are using, because I think this 
error had been trapped in recent versions.

Bets wishes,

Andrew







On 30 May 2015, at 09:45, Tom Wong wangnan4...@yahoo.co.jp wrote:

 Dear everyone:
 
 Recently I met a mtz format problem: after I processed a data by iMosflm and 
 scaled by AIMLESS. 
 The mtz file could not be processed for further phasing by shelx, it said:
 
 ** Input file /home/tom/ccp4test_6_1_sca.tmp.sca corrupted at line   7 **
 0   0   6 38460.7  
 
 
 
 Later I use mtz2various program to convert that mtz to sca, i got this:
 
 
   54.66075.31475.31490.00090.00090.000 p 21 21 21
0   0   372.269.2
0   0   4 25749.5  1366.3
0   0   544.463.6
0   0   6 38460.7
0   0   746.162.7
0   0   8  1413.8   288.1
0   0   9-2.957.4
0   0  10424115.3 11976.6
 
 
 I think it is a format conflict problem between iMosflm and shelx.
 Is there anyone who can help me get through this?
 How to do the phasing by using the mtz generated by iMosflm?
 
 
 Thank you very much!
 
 
 Tom

[ccp4bb] Two Postdoctoral Scientist positions at MRC LMB Cambridge

[Andrew Leslie]

Posted on behalf of Chris Tate:

Postdoctoral Scientist x 2

Structural biology of ion channels by cryo-EM

Starting Salary £27,084 – £32,324

Band Salary £27,084 – £39,873

MRC Laboratory of Molecular Biology

Two Pfizer-funded Investigator Scientist or Postdoctoral Scientist positions 
are available, for a period of 3 years, to work on the structural biology of 
mammalian ion channels using the latest technology in single-particle electron 
cryo-microscopy. You will work under the supervision of Group Leaders Dr Sjors 
Scheres and Dr Chris Tate.

Ideal candidates will be highly motivated with a track record of working on 
integral membrane proteins and expertise in at least one, and preferably more, 
of the following areas: over-expression in insect or mammalian cells, membrane 
protein purification, and electron cryo-microscopy structure determination. 
Candidates must be self-motivated individuals who enjoy working as part of a 
collaborative, multidisciplinary team.  Strong leadership, communication and 
teamwork skills are decided assets. 

The successful candidate will be appointed as either Investigator Scientist or 
on a MRC Career Development Fellowship/MRC Postdoctoral Training Scheme for a 
three year period. MRC Career Development Fellowship/MRC Postdoctoral Training 
Scheme is a training and development position for a Postdoctoral Scientists who 
have recently completed doctoral studies or are moving into a new research 
discipline. Starting Salary and position appointed to will be dependent on 
research experience.

The research will be conducted at the MRC Laboratory of Molecular Biology (LMB) 
in Cambridge, UK (http://www2.mrc-lmb.cam.ac.uk). The institute has a long 
history of excellence. The new LMB building was recently inaugurated and offers 
state-of-the-art facilities.

Applications are handled by UK Shared Business Services; for further 
information and to apply please visit our job board at 
http://www.topcareer.jobs If you are unable to apply online please contact us 
on 01793 867000 quoting reference IRC190753.

 

Closing date: 7th June 2015

 

Final appointments will be subject to a pre-employment screening

The Medical Research Council is an Equal Opportunities Employer

[ccp4bb] Reading coords and maps in COOT for PDB entries in mmcif format

[Andrew Leslie]

I am trying to get coordinates and maps into COOT for a PDB entry that is only 
in mmcif format. 

If I select any of the Fetch PDB … options in COOT, I get the following error 
message:

DEBUG:: in get-url-str: 4wz7 
http://www.ebi.ac.uk/pdbe-srv/view/files/4wz7.ent; pdb
(handle-read-draw-molecule-with-recentre coot-download/4wz7.pdb.ent 0)
Reading coordinate file: coot-download/4wz7.pdb.ent
There was an error reading coot-download/4wz7.pdb.ent. 
ERROR 20 READ: Attempt to read unknown-type file.
No Spacegroup found for this PDB file
There was a coordinates read error
PDB Accession Code: 4wz7

If I download the mmcif PDB file and read it into COOT using the Open 
coordinates option then this works OK, so I can get the coordinates but I 
cannot get the density map. 

If I go direct to the EDS server (http://eds.bmc.uu.se/eds/) and put in the PDB 
code I get the error message Sorry, there is no structure factor entry for 
4wz7.

Does anyone know an easy way around this to get the maps into COOT, or do I 
just have to download the mmcif structure factor file and use a program (e.g. 
refmac) to calculate the map coefficients ?

I am using COOT version 0.8.1 EL (ccp4).

Thanks,

Andrew

Re: [ccp4bb] Thin plate crystals

[Andrew Leslie]

There have been quite a few reports that the addition of a low concentration of 
alcohol (e.g. isopropanol, a few %) can help to increase the thickness of thin 
plate crystals like these. However, these are probably in the Hampton additive 
screen that David Briggs suggested.

Good luck,

Andrew

On 24 Apr 2015, at 04:01, Prerana G. tracy...@gmail.com wrote:

 Dear all,
 
 I am working on a protein (40kDa) which forms very thin plate shaped crystals 
 which diffracts at very low resolution. Protein concentration that i have 
 used for crystallisation is approx. 8mg/ml. I have attached the picture of 
 the protein crystal.
 
 
 How can I improve upon the shape of the crystal?
 Crystal_1.jpg

Re: [ccp4bb] Absence of contact between layers in a crystal

[Andrew Leslie]

Just to give a concrete example of Randy's point, PDB entry 2ts1 for tyrosyl 
tRNA synthetase has layers of molecules with no contact between the layers. 
This is because the domain (residues 320-419) that was providing the contacts 
in this direction was disordered and could not be modelled (there was very 
little density in this region). It is perhaps surprising that in spite of the 
disorder the crystals diffracted very well (2.3Å data collected on film).

Andrew

On 6 Feb 2015, at 11:16, Randy Read rj...@cam.ac.uk wrote:

 Actually, if you go back through the archive of CCP4-BB from the first time 
 this came up, I think you'll find that there are real crystals with apparent 
 gaps in the packing.  This can arise because of statistical disorder, where 
 there are two or more ways that a statistically-disordered layer in the 
 crystal can mediate the interaction between ordered layers.  So not finding a 
 connected packing is something to look closely at and worry about, but it 
 doesn't necessarily indicate that somebody did a bad job of making up a 
 structure.
 
 Randy
 
 On 6 Feb 2015, at 11:09, Robbie Joosten robbie_joos...@hotmail.com wrote:
 
 Not in real crystal structures ;)
 
 Cheers,
 Robbie
 
 Sent with my Windows Phone
 Van: Kerff Fred
 Verzonden: ‎6-‎2-‎2015 12:02
 Aan: CCP4BB@JISCMAIL.AC.UK
 Onderwerp: [ccp4bb] Absence of contact between layers in a crystal
 
 Hello,
 
 Looking at structure 2HR0 (The structure of complement C3b provides 
 insights into complement activation and regulation. »,Abdul Ajees, A.,  
 Gunasekaran, K.,  Volanakis, J.E.,  Narayana, S.V.,  Kotwal, G.J.,  Krishna 
 Murthy, H.M.;  (2006) Nature 444: 221-225), I noticed the absence of 
 contacts between layers in the crystal. Is it something that has already 
 been observed in other crystals?
 
 Best regards,
 
 Fred
 -
 Frédéric Kerff
 Chercheur qualifié F.R.S.-FNRS
 Cristallographie des protéines
 Centre d'Ingénierie des Protéines
 Université de Liège
 17, Allée du 6 Août - Bat B5a
 4000 Liège (Belgium)
 Tel.: +32 (0)4 3663620
 Fax: +32 (0)4 3663772
 
 
 
  Le 6 févr. 2015 à 10:12, Tim Gruene t...@shelx.uni-ac.gwdg.de a écrit :
  
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Dear Smith,
  
  The sca file most likely does not contain flags. pointless can read
  the sca file, standardise it to ccp4 standards and freerflag marks
  random reflections. You should use the maximum of 500 unique
  reflections or 5% of the unique reflections, whichever is larger.
  
  Best,
  Tim
  
  On 02/06/2015 09:49 AM, Smith Lee wrote:
  Dear All, I have a sca file. Will you please tell me by which
  software or how I can know whether the sca file contains R-free
  tags? If not, by which software or how I can add the R-free tags?
  And how much of the reflections I add the R-free tags? I am looking
  forward to getting your reply. Smith
  
  
  - -- 
  - --
  Dr Tim Gruene
  Institut fuer anorganische Chemie
  Tammannstr. 4
  D-37077 Goettingen
  
  GPG Key ID = A46BEE1A
  
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.12 (GNU/Linux)
  
  iD8DBQFU1IWVUxlJ7aRr7hoRAmZHAJ4+6wREnwkFN0EhfErAA0tPSopKKwCgiLdi
  j0JFZac4kAh8twpov71MG84=
  =XN57
  -END PGP SIGNATURE-
 
 --
 Randy J. Read
 Department of Haematology, University of Cambridge
 Cambridge Institute for Medical Research  Tel: + 44 1223 336500
 Wellcome Trust/MRC Building   Fax: + 44 1223 336827
 Hills RoadE-mail: rj...@cam.ac.uk
 Cambridge CB2 0XY, U.K.   www-structmed.cimr.cam.ac.uk
 

Re: [ccp4bb] X-ray Source Differences (WAS: RE: [ccp4bb] How far does rad dam travel?)

[Andrew Leslie]

Hi Tim, Jacob,

 I must admit that I was very surprised by the 
suggestion of a top-hat profile for a in-house rotating anode. We have a Rigaku 
Fr-E generator, and Rigaku provided a plot of the beam profile for that (with 
VariMax-HR Optic) and it is very far from being top hat, much more 
Gaussian-like, which really is what I would have expected for this type of 
source and optic. 

Without significantly truncating the full profile (i.e. by selecting the very 
central part of a Gaussian, which results in a significant loss of flux) I 
don't know how they would achieve a top hat profile, but perhaps someone from 
Bruker could respond to this ? I guess my point is that certainly not all in 
house generators provide a beam with a top hat profile.

Best wishes,

Andrew

On 12 Jan 2015, at 21:38, Tim Gruene t...@shelx.uni-ac.gwdg.de wrote:

 Hi Jacob,
 
 at the beginning of my experience of S-SAD about 10 years ago, it was
 not too difficult to do S-SAD phasing with inhouse data provided the
 resolution was better than 2.0A, while it did not always work with
 synchrotron data. Purely personal experience.
 
 However, the inhouse machines I am familiar with have three circles, so
 that you get much better real redundancy with equivalent reflections
 recorded at different settings. This reduces systematic errors, I think.
 The most sophisticated synchrotron beamline I have been to offered a
 mini-kappa with 30degree range - that's not much compared to 10-20
 different settings with varying phi- omega- and distance settings.
 
 The top-hat comes from a quote I received from Bruker, and I have no
 reason to believe the person acted purely with a salesperson's intent.
 
 Best,
 Tim
 
 On 01/12/2015 09:05 PM, Keller, Jacob wrote:
 the top-hat profile is one of the reasons why inhouse machines produce 
 better quality data than synchrotrons. However, the often much increased 
 resolution you achieve at the synchrotron is generally worth more than the 
 quality of the data at restricted resolution.
 
 Cheers,
 Tim
 
 Several surprises to me:
 
 -Data from in-house sources is better?
  I have not heard of this--is there any systematic examination of this? 
 I saw nothing about this in a very brief Google foray.
 
 -In-house beam profiles are top-hats?
  Is there a place which shows such measurements? Does not pop out of 
 Google for me, but I would love to be shown that this is true.
 
 -Resolution at the synchrotron is better?
  This does not really seem right to me theoretically, although in 
 practice it does seem to happen. I think it is just a question of waiting 
 for enough exposure time, as the CCP4BB response quoted at bottom describes.
 
 JPK
 
 
 
 ===
 
 
 Date: Tue, 12 Oct 2010 09:04:05 -0700
 From: James Holton jmhol...@lbl.gov
 Re: Re: Lousy diffraction at home but fantastic at the synchrotron?
 There are a few things that synchrotron beamlines generally do better than 
 home sources, but the most important are flux, collimation and absorption.
 Flux is in photons/s and simply scales down the amount of time it takes to 
 get a given amount of photons onto the crystal. Contrary to popular belief, 
 there is nothing magical about having more photons/s: it does not somehow 
 make your protein molecules behave and line up in a more ordered way. 
 However, it does allow you to do the equivalent of a 24-hour exposure in a 
 few seconds (depending on which beamline and which home source you are 
 comparing), so it can be hard to get your brain around the comparison.
 Collimation, in a nutshell, is putting all the incident photons through the 
 crystal, preferably in a straight line. Illuminating anything that isn't the 
 crystal generates background, and background buries weak diffraction spots 
 (also known as high-resolution spots). Now, when I say crystal I mean the 
 thing you want to shoot, so this includes the best part of a bent, cracked 
 or otherwise inhomogeneous crystal. The amount of background goes as the 
 square of the beam size, so a 0.5 mm beam can produce up to 25 times more 
 background than a 0.1 mm beam (for a fixed spot intensity).
 Also, if the beam has high divergence (the range of incidence angles onto 
 the crystal), then the spots on the detector will be more spread out than if 
 the beam had low divergence, and the more spread-out the spots are the 
 easier it is for them to fade into the background. Now, even at home 
 sources, one can cut down the beam to have very low divergence and a very 
 small size at the sample position, but this comes at the expense of flux.
 Another tenant of collimation (in my book) is the DEPTH of non-crystal 
 stuff in the primary x-ray beam that can be seen by the detector. This 
 includes the air space between the collimator and the beam stop. One 
 millimeter of air generates about as much background as 1 micron of crystal, 
 water, or plastic. Some home sources have ridiculously large air 

[ccp4bb] Bond lengths and angles used by Molprobity for ANP (AMPPNP)

[Andrew Leslie]

Does anyone know if Molprobity has recently changed the standard bond lengths 
and angles that it uses ?  

Molprobity is reporting errors in the C4-C5 bond length and the C5-C4-N3 bond 
angle (deviations of 8-10 sigma) for AMPPNP (monomer code ANP) for a new 
structure refined with Refmac. I then tried Molprobity on a deposited PDB 
structure that also contains AMPPNP and it reported the same errors. I am sure 
that these errors were not reported when this structure (2JDI) was deposited in 
2007.

This would suggest that the standard dictionary that Molprobity uses has 
changed, but I cannot find any reference to this on the Molprobity pages. 

I would be very grateful if anyone can throw some light on this.

Thanks,

Andrew

Re: [ccp4bb] Bond lengths and angles used by Molprobity for ANP (AMPPNP)

[Andrew Leslie]

Dear Huw,

Many thanks for this information. I had seen the notice about Molprobity using 
CCTBX validation metrics, but I mistakenly thought that Phenix used the CCP4 
monomer library, which I think was true once but is clearly no longer the case. 

Given the very small sigma values associated with the Phenix C4-C5 bond length, 
it could be said to differ by 10.4 standard deviations from the CCP4 monomer 
library value !

Many thanks to all others who have responded too. 

In response to Dale's comment, the frustrating thing is that this is not 
interesting at all, it is merely confusing. The resolution of the new structure 
is only ~3 Å, so there is no way that one can make meaningful statements about 
distortions from standard geometry. The warnings merely highlight the fact that 
we do not have adequate library entries.

Best wishes,

Andrew



On 15 Sep 2014, at 17:14, Huw Jenkins h.t.jenk...@me.com wrote:

   
 On 15 Sep 2014, at 15:24, Andrew Leslie and...@mrc-lmb.cam.ac.uk wrote:
 
 This would suggest that the standard dictionary that Molprobity uses has 
 changed, but I cannot find any reference to this on the Molprobity pages. 
 
 I would be very grateful if anyone can throw some light on this.
 
 MolProbity now uses the same target values as Phenix:
 
 MolProbity4 structure validation now provides many of its validation metrics 
 through CCTBX, the open-source component of the Phenix crystallographic 
 package. CCTBX allows for consistent validation results with Phenix, as well 
 as added functionality, such as geometry regularization of NQH flips” 
 
 The target values for the C4-C5 bond length and the C5-C4-N3 bond angle are 
 quite different in the two libraries:
 
 
 ccp4-6.4.0/lib/data/monomers/a/ANP.cif 
 
 ANP  C4 C5double  1.4900.020
 
 ANP  C5 C4 N3  120.0003.000
 
 phenix-1.9-1692/chem_data/geostd/a/data_ANP.cif 
 
 ANP   C5  C4aromatic  1.386 0.010
 
 ANP   N3  C4  C5  126.80 0.741
 
 That explains the 8-10 sigma deviations reported by MolProbity but it doesn’t 
 explain which target values are (more) correct. 
 
 
 
 Huw

Re: [ccp4bb] ATP library file in REFMAC

[Andrew Leslie]

Hi Bernie,

   This is an issue that the REFMAC developers and the PDB are 
aware of (at least at the EBI site) and that we have also encountered in a 
recent deposition. The problem is that there is indeed a discrepancy between 
the stereochemistry for ATP and ADP as defined in the CCP4 monomer libraries 
and that defined by Mogul that the PDB now uses for its validation report. As 
both REFMAC and PHENIX make use of the CCP4 monomer library, this will affect 
the majority of depositions with the PDB, but will only have been picked up 
since PDB introduced their new validation software. I therefore suspect that 
almost all PDB entries for ATP/ADP would fail the new validation test.

There is a working group being set up (funded by CCP4 I believe) to address 
issues of errors in the CCP4 monomer library, and this will, in time, sort out 
these issues. It think that a significant number of other ligand library 
entries may also contain errors.

Best wishes,

Andrew


On 27 Aug 2014, at 16:12, Bernard D Santarsiero b...@uic.edu wrote:

 I recently refined a structure in CCP4/REFMAC with ATP in the structure. Upon 
 submission to Acta for publication, the wwPDB validation report was run. 
 Several things were flagged, including the C4-C5 bond in the adenosine moiety 
 as being too long. It generally refines to 1.46-1.47A. The ideal distance 
 in the validation report is 1.38A, and the upon review of the ATP.cif file in 
 the REFMAC library, the target distance is 1.49A (and listed as a double 
 bond). Clearly 1.37-1.38A is a reasonable target value. HIC-Up gives the 
 target bond length as 1.404A.
 
 Where can I grab a revised ATP.cif file? I guess I'll need to re-refine all 
 of my structures and re-run the validation report.
 
 BTW, I also looked at the PDB_REDO structure report for my structure, and 
 can't reproduce the Rcryst and Rfree values with the same model.
 
 Bernie
 -- 
 Bernard D. Santarsiero
 Research Professor
 Center for Pharmaceutical Biotechnology and the
  Department of Medicinal Chemistry and Pharmacognosy
 Center for Structural Biology
 Center for Clinical and Translational Science
 University of Illinois at Chicago
 MC870  3070MBRB  900 South Ashland Avenue
 Chicago, IL 60607-7173  USA
 (312) 413-0339 (office)
 (312) 413-9303 (FAX)
 http://www.uic.edu/labs/bds 
 http://scholar.google.com/citations?user=fGauLBMJ
 

Re: [ccp4bb] Rename chain ID of water molecules

[Andrew Leslie]

Dear Wehne,

Have you looked at the CCP4 program watertidy … I think it does what you want 
(but I have not used it myself).

Andrew


On 3 Jul 2014, at 04:42, Wenhe wenhezhong.xmu@gmail.com wrote:

 Dear CCP4BB members,
 
 I want to keep the chain ID of water molecules the same as their interacting 
 protein molecule. For example, I have two protein molecules in the structure 
 —— named chain A and chain B; then I want all the water molecules interacting 
 with protein A (or B) have the same chain name A (or B). 
 
 Any tool in CCP4 can do this? I remembered that when we deposited our 
 coordinates to PDB, the server can do this automatically. Thank you.
 
 Kind regards,
 Wenhe

Re: [ccp4bb] Helix alignment and movement

[Andrew Leslie]

Dear Mike,

   I think that the old CCP4 superpose program used to be 
able to do this ? (This was a FORTRAN program, based on code from Wayne 
Hendrickson's PROLSQ program). With this program you specify one set of 
residues to do the alignment with and another set to do the statistics on 
(after alignment).

I don't know if this is still in the CCP4 archive somewhere, but I do have a 
copy of the source code that I could let you have.

Best wishes,
Andrew

On 13 May 2014, at 14:59, R. M. Garavito rmgarav...@gmail.com wrote:

 Dear Eugene and other CCP4ers
 
 The recent discussion about superposition has prompted me to ask about a 
 different kind of superposition problem.  We are working on a small dimeric 
 protein that is entirely made up of helices.  Instead of large, concerted 
 domain movements, which I am quite familiar with, we have 3 structures for 
 the dimer that display slightly, but significantly different helical 
 conformations.  I have been able to find the minimal substructure that allows 
 the best superposition (lowest RSMD and maximum number of 
 aligned/superimposed C-alphas).
 
 The problem is that none of the superposition programs available outputs a 
 list of residue by residue deviations OUTSIDE of the alignment set (for good 
 reason as there may not be 1 to 1 correspondence outside of this set).  I can 
 do some of this in a piecemeal fashion with Moleman2, but not everything I 
 want.  My question is, after creating an optimal structural alignment, are 
 there newer programs that:
 
 (1) Create a list of residue by residue deviations over different subsets of 
 the structure, particularly OUTSIDE of an alignment set? 
 
 (2) Localize and measure movement of secondary structure (helix tilt or 
 bending)?
 
 I can't seem to find what I need, but I may not be searching with the right 
 key words.
 
 Thanks,
 
 Michael
 
 
 R. Michael Garavito, Ph.D.
 Professor of Biochemistry  Molecular Biology
 603 Wilson Rd., Rm. 513   
 Michigan State University  
 East Lansing, MI 48824-1319
 Office:  (517) 355-9724 Lab:  (517) 353-9125
 FAX:  (517) 353-9334Email:  rmgarav...@gmail.com
 
 
 
 
 
 On May 11, 2014, at 7:14 AM, Eugene Krissinel eugene.krissi...@stfc.ac.uk 
 wrote:
 
 My guess is that only atom pairs that are superposed to some measure of 
 distance between them, are output. Can't say that I checked lsqkab code this 
 weekend, but documentation does not suggest anything like that.
 
 Is this a problem for you? note that you can use other aligners/superposers 
 in CCP4, ssm or Gesamt which will output all coordinates.
 
 Eugene
 
 

Re: [ccp4bb] metals disapear

[Andrew Leslie]

Dear All,

   So there has been quite a bit of advice on minimising radiation 
damage, and on some of the effects of radiation damage, but unless I have 
missed it no-one has come up with a clear cut case where radiation damage 
actually resulted in the (complete ?) loss of a metal ion. 

This makes Felix's question all the more relevant: In this particular case, is 
there any certainty that the metal was there in the first place ? I know, for 
example, that the catalytic metals are often missing in the binary complexes of 
polymerases (protein + oligo but no incoming NTP), but this is not due to 
radiation damage. Equally, in F1-ATPase we sometimes have a nucleotide bound 
without the coordinative Mg ion.

I realise that Dean may not be able to give full details as this may be 
commercially sensitive.

Best wishes,

Andrew


On 30 Apr 2014, at 11:33, Dean Derbyshire dean.derbysh...@medivir.com wrote:

 Hi all,
 Has anyone experienced catalytic metal ions disappearing during data 
 collection ?
 If so, is there a way of preventing it?
 D.
  
Dean Derbyshire
Senior Research Scientist
 image001.jpg
Box 1086
SE-141 22 Huddinge
SWEDEN
Visit: Lunastigen 7
Direct: +46 8 54683219
www.medivir.com
  
 --
 This transmission is intended for the person to whom or the entity to which 
 it is addressed and may contain information that is privileged, confidential 
 and exempt from disclosure under applicable law. If you are not the intended 
 recipient, please be notified that any dissemination, distribution or copying 
 is strictly prohibited. If you have received this transmission in error, 
 please notify us immediately.
 Thank you for your cooperation.

Re: [ccp4bb] metals disapear - sidetrack - helical scans

[Andrew Leslie]

I would just like to back up Ruslan's comments. We have certainly found helical 
scans to be very valuable at the ESRF and Diamond in minimising radiation 
damage particularly in cases there the crystal is elongated approximately along 
the rotation axis direction and where there is not full control over the beam 
size (in both horizontal and vertical directions). Of course this depends on 
setting the experimental parameters appropriately, as Ruslan described.

Cheers,

Andrew

On 1 May 2014, at 02:03, Sanishvili, Ruslan rsanishv...@anl.gov wrote:

 The question about metal sensitivity to radiation cannot be answered in
 general; it needs to be discussed in specific chemical coordination
 context.
 
 Agreed. The author of the original question should have provided more details 
 about the metal in question, about the samples and the way experiment was 
 carried out.
 
 The advice about using helical scan is horrible in this context. The
 diffraction collected by such method represents state of crystal exposed
 to constant high dose. If anything, the helical scan method is more
 suitable to study radiation damaged state of the crystal.
 
 I am afraid the advise was horribly misunderstood. A crystal during helical 
 data collection doesn't have to be exposed to constant high dose. The 
 exposure level is selected by the experimenter and is not intrinsic feature 
 of helical data collection. The advise comprised a four-step program and it 
 started by determining (in the first step) a lower dose that would still 
 allow making valid enzymologic (or mechanistic) conclusions. Then further 
 steps instructed how to lower this dose even more by using multiple crystals 
 (if necessary due to poor crystals quality - 2nd step), or by spreading the 
 same low dose over a larger volume using helical data collection - step 4.
 I suspect the misunderstanding is based on a misconception that if one is 
 using helical data collection, one necessarily is using small beam and high 
 intensity, but it is not so at all. The beam size to be used is dictated by 
 the size of the well-diffracting volume (advised to determine in step #3). If 
 one has large well-diffracting volume, large beam can be used for helical 
 data collection as well (if the volume is larger than the beam size).
 Hope it clarifies things little better.
 Cheers,
 N. 
 
 
 Ruslan Sanishvili (Nukri)
 Macromolecular Crystallographer
 GM/CA@APS
 X-ray Science Division, ANL
 9700 S. Cass Ave.
 Lemont, IL 60439
 
 Tel: (630)252-0665
 Fax: (630)252-0667
 rsanishv...@anl.gov
 
 
 
 From: zbys...@work.swmed.edu [zbys...@work.swmed.edu]
 Sent: Wednesday, April 30, 2014 10:33 AM
 To: Sanishvili, Ruslan
 Cc: ccp4bb@jiscmail.ac.uk
 Subject: Re: [ccp4bb] metals disapear
 
 If metal ion will be sensitive to radiation depends on its redox chemistry
 and not its X-ray properties. For a metal to be affected by radiation dose
 it needs to be reduced by free radicals. However, such metals are rarely
 (by gene counts or deposits in PDB) present in catalytic sites of enzymes.
 The most frequently occurring metal ions in catalytic sites e.g. Mg++,
 Ca++, Zn++, Fe++, Mn++ lack oxidation state to which they could be reduced
 by a single radical. For this reason these metals tend to be very stable
 upon radiation and they are last to go. Copper is the counterexample where
 radiation sensitivity is much more likely to be expected.
 
 Unfortunately, the original question and part of the discussion involved
 generic category of metals involved in catalysis, rather then specific
 one.
 Magnesium is by far the the most frequently encounter metal in catalytic
 sites. In redox reaction the most frequent cofactors are not metals, but
 NAD or FAD. Iron is most often present in Fe-S clusters rather than as
 standalone Fe++ ion. These clusters are structurally diverse and do not
 necessarily participate in catalysis. If they have similar or diverse
 sensitivity to radiation is not clear to me.
 
 The question about metal sensitivity to radiation cannot be answered in
 general; it needs to be discussed in specific chemical coordination
 context.
 
 
 Separate issue:
 
 The advice about using helical scan is horrible in this context. The
 diffraction collected by such method represents state of crystal exposed
 to constant high dose. If anything, the helical scan method is more
 suitable to study radiation damaged state of the crystal.
 
 Zbyszek Otwinowski
 
 Dear Dean,
 
 You have already received excellent insight into radiation effects on
 metals. From personal experience, it doesn't take long for the metal
 occupancy to go down to 80%. Of course it is not anywhere near
 disappearing but then again, we don't know the details of your data
 collection and of how disappeared are your disappeared metals.
 
 I will only add that you can use modern approaches to data collection to
 minimize the adverse effects of radiation.
 
 1. Do not chase the highest 

Re: [ccp4bb] metals disapear

[Andrew Leslie]

Can the radiation damage gurus comment on this ? I know there is a problem with 
radiation damage changing the valence state of metals, but I don't remember 
hearing about the metal actually being lost due to radiation damage. Is this 
really common ?

Thanks,

Andrew

On 30 Apr 2014, at 11:46, Tim Gruene t...@shelx.uni-ac.gwdg.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Dear Dean,
 
 this is probably a very common observation: X-rays produce reducing
 electrons and as you reduce a metal I imagine it does not like its
 chemical environment as much as it did highly charged.
 
 Everything you can do to avoid radiation damage should help you
 prevent the ion to disappear:
 - - optimise your strategy to collect a minimal amount of data
 - - add vitamin C
 - - cool below 100K
 - - collect at short wavelength
 
 When your ion is intended to be used for phasing there are of course
 restraints limiting the choice.
 
 Regards,
 Tim
 
 
 On 04/30/2014 12:33 PM, Dean Derbyshire wrote:
 Hi all, Has anyone experienced catalytic metal ions disappearing
 during data collection ? If so, is there a way of preventing it? 
 D.
 
 Dean Derbyshire Senior Research Scientist 
 [cid:image001.jpg@01CF6470.5FA976D0] Box 1086 SE-141 22 Huddinge 
 SWEDEN Visit: Lunastigen 7 Direct: +46 8 54683219 
 www.medivir.comhttp://www.medivir.com
 
 --
 
 
 This transmission is intended for the person to whom or the entity to
 which it is addressed and may contain information that is privileged,
 confidential and exempt from disclosure under applicable law. If you are
 not the intended recipient, please be notified that any dissemination,
 distribution or copying is strictly prohibited. If you have received
 this transmission in error, please notify us immediately.
 Thank you for your cooperation.
 
 
 - -- 
 - --
 Dr Tim Gruene
 Institut fuer anorganische Chemie
 Tammannstr. 4
 D-37077 Goettingen
 
 GPG Key ID = A46BEE1A
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
 
 iD8DBQFTYNSPUxlJ7aRr7hoRAr7WAKCzC7FzqTkcVLILovmIL74OUQlsWQCgg2Yr
 xZgDCvIlf5YEWHLTDLiKcRc=
 =tp4F
 -END PGP SIGNATURE-

Re: [ccp4bb] twinning problem ?

[Andrew Leslie]

Dear Stephen,

I have seen a similar effect in the structure of 
F1-ATPase complexed with the full length inhibitor protein. The inhibitor is a 
dimer, and it actually couples 2 copies of the ATPase, but it crystallised with 
only one copy of the ATPase per asymmetric unit. When I solved the structure by 
MR, I saw additional density that could not be accounted for. The extra density 
was, in fact, a second ATPase molecule that was related to the first by a 120 
degree rotation about the pseudo 3-fold axis of the enzyme. The dimers were 
packing with statistical disorder in the crystal lattice. This gave rise to 
clear streaking between Bragg spots in the diffraction images in a direction 
that was consistent with that expected from the statistical packing of the 
inhibitor linked dimers.

Two copies of F1 were included in the refinement, each with occupancy 0.5. the 
final Rfree was 27.7% (2.8A data). Prior to introduction of the second copy of 
F1, the Rfree was 37%.

More details are in Cabezon et al., NSMB 10, 744-750, 2003

Best wishes,

Andrew



On 11 Mar 2014, at 14:04, Stephen Cusack cus...@embl.fr wrote:

 Dear All,
I have 2.6 A data and unambiguous molecular replacement solution for two 
 copies/asymmetric unit of a 80 K protein for a crystal integrated
 in P212121 (R-merge around 9%) with a=101.8, b=132.2, c=138.9.
 Refinement allowed rebuilding/completion of the model in the noraml way but 
 the R-free does not go below 30%. The map in the model regions looks 
 generally fine but  there is a lot
 of extra positive density in the solvent regions (some of it looking like 
 weak density for helices and strands)  and unexpected positive peaks within 
 the model region.
 Careful inspection allowed manual positioning of a completely different, 
 overlapping solution for the dimer which fits the extra density perfectly.
 The two incompatible solutions are related by a 2-fold axis parallel to a.
 This clearly suggests some kind of twinning. However twinning analysis 
 programmes (e.g. Phenix-Xtriage), while suggesting the potentiality
 of pseudo-merohedral twinning (-h, l, k) do not reveal
 any significant twinning fraction and proclaim the data likely to be 
 untwinned. (NB. The programmes do however highlight a
 non-crystallographic translation and there are systematic intensity 
 differences in the data). Refinement, including this twinning law made no 
 difference
 since the estimated twinning fraction was 0.02. Yet the extra density is 
 clearly there and I know exactly the real-space transformation between the 
 two packing solutions.
 How can I best take into account this alternative solution (occupancy seems 
 to be around 20-30%) in the refinement ?
 thanks for your suggestions
 Stephen
 
 -- 
 
 **
 Dr. Stephen Cusack,   
 Head of Grenoble Outstation of EMBL
 Group leader in structural biology of protein-RNA complexes and viral proteins
 Joint appointment in EMBL Genome Biology Programme
 Director of CNRS-UJF-EMBL International Unit (UMI 3265) for Virus Host Cell 
 Interactions (UVHCI)
 **
 
 Email:cus...@embl.fr  
 Website: http://www.embl.fr   
 Tel:  (33) 4 76 20 7238Secretary (33) 4 76 20 7123
 
 Fax:(33) 4 76 20 7199 
 Postal address:   EMBL Grenoble Outstation, 6 Rue Jules Horowitz, BP181, 
 38042 Grenoble Cedex 9, France
 Delivery address: EMBL Grenoble Outstation, Polygone Scientifique,
  6 Rue Jules Horowitz, 38042 Grenoble, France
 **

Re: [ccp4bb] Large Conformational Change Upon Binding Ligand...

[Andrew Leslie]

Dear Jacob,

Citrate synthase is another early (historically) case, and GAPDH (on binding 
NAD). 

Andrew

On 27 Feb 2014, at 19:43, Keller, Jacob kell...@janelia.hhmi.org wrote:

 Dear Crystallographers,
 
 Does anyone know of good examples of large, reversible conformational changes 
 occurring between ligand-free and -bound states? Could also be a non-relevant 
 molecule binding, like sulfate or something inducing dubiously -relevant 
 changes. I already know of the calmodulin and periplasmic binding protein 
 families, but does anyone know of others out there?
 
 All the best,
 
 Jacob Keller
 
 ***
 Jacob Pearson Keller, PhD
 Looger Lab/HHMI Janelia Farms Research Campus
 19700 Helix Dr, Ashburn, VA 20147
 email: kell...@janelia.hhmi.org
 ***

Re: [ccp4bb] Examples of multiple ASU copies with different conformations

[Andrew Leslie]

Dear Shane,

 To add a bit of detail to Frank von Delft's suggestion, 
perhaps the best example is the structure of the yeast F1-ATPase that has 3 
copies in the asu, from David Mueller's lab in Chicago. Two of these are very 
similar, but the third is rather different and shows a (physiologically 
relevant) phosphate binding site that is not found in the other two copies. I 
would not describe the differences as dramatic though.

The paper is: Kabaleeswaran et al., EMBO J 25, 5433 (2006)

PDB ID 2HLD

Best wishes,

Andrew Leslie

On 27 Jan 2014, at 18:08, Shane Caldwell shane.caldwel...@gmail.com wrote:

 Hi ccp4bb,
 
 I'm putting together a talk for some peers that highlights strengths and 
 weaknesses of structural models for the outsider. For one point, I'd like to 
 find some examples of proteins that show very different conformations between 
 different copies in the ASU. One example I know of is c-Abl (1OPL), which 
 crystallizes with both autoinhibited and active forms in the ASU, with 
 dramatically different domain organization. I'd like to find some additional 
 examples - can anyone suggest some other structures that have multiple copies 
 with large structural variations?
 
 Thanks in advance!
 
 Shane Caldwell
 McGill University
 
 

Re: [ccp4bb] Observed criterion sigma(I|F)

[Andrew Leslie]

Hi Graeme,

There was a CCP4BB thread about this quite recently (14th Nov 2013). I've coped 
below responses from Edward Berry and Matthew Franklin.

SCALA  AIMLESS have no sigma cutoffs, but TRUNCATE does. According to the 
documentation, reflections with intensities  less than minus 4 standard 
deviations are rejected. However, in the code this seems to be less than minus 
3.7 standard deviations (rather than 4). So for data that has been processed by 
TRUNCATE, I think that the observed criterion sigma(I) is -3.7. This is 
hard-wired in the code.

It is interesting (perhaps) that this number only seems to be requested for PDB 
depositions processed by RCSB, PDBe do not seem to ask for this (at least, not 
the last time I deposited).

Andrew



Edward Berry:
As I understand it this refers to the decision whether an observation is valid 
or not, and the default value in HKL suite is -3 sigma (note the negative 
sign). The
denzo/scalepack manual explains that while it is important not to exclude 
observations
that are slightly negative due to random errors of measurement, anything that 
comes
in below -3 sigma is likely to be a fluke and should be discarded.
I'm not sure whether this refers to measurements before adding partials, or to 
the
summed full reflection observation.  anyway, I always put -3s for that value
and haven't had any negative feedback from the annotators.

Matthew Franklin:

HKL2000 (Denzo/Scalepack) use I greater than -3 sigma (that's NEGATIVE 3) as 
the observed criterion, so that's what you would put down for this entry.  
There is another place where you're asked to provide an observed criterion for 
F's used during refinement.  I always put down 0 (i.e. use all F's) for this 
one.

I have no idea what Scala does.




On 25 Nov 2013, at 09:21, Graeme Winter graeme.win...@gmail.com wrote:

 Hi Folks,
 
 A xia2 user wrote in asking where to find
 
 'observed criterion sigma(F)' and 'observed criterion sigma(I)'
 
 in the xia2 logs (i.e. from Scala or Aimless or XSCALE)... I have no idea 
 what they are so will struggle to give a helpful answer ;o) and surprisingly 
 google was not a lot of use coming up with
 
 Data processing information : high and low resolution limits, observed 
 criterion sigma (F) cut-off or observed criterion sigma (I) cut-off, number 
 of unique measured reflections (all and observed), percent of possible 
 reflections observed, R-merge I (observed) or R-sym I (observed), details 
 about the highest resolution shell 
 
 Can anyone point me in the right direction?
 
 Thanks in advance  best wishes, Graeme

Re: [ccp4bb] Fix cell dimensions

[Andrew Leslie]

Dear Niu,

It depends on which part of processing you are referring to, 
i.e. the indexing step or the integration step. In MOSFLM there is no way to 
enforce cell dimensions during indexing, but providing there is an indexing 
solution that has cell dimensions close to the ones you want, you can enforce a 
(slightly) different set of cell dimensions during the integration step. 
Normally other refined parameters will ensure that you still get a good 
prediction of spot positions.

I suspect that this can be done in other programs too.

Without knowing why you want to do this, I cannot comment on whether this is 
the best procedure to follow.

Best wishes,

Andrew



On 18 Nov 2013, at 21:48, Niu Tou niutou2...@gmail.com wrote:

 Dear All,
 
 Does any one know how to strictly fix the cell dimensions during data 
 processing? In HKL2000 there is only a keyword to define the longest vector. 
 In XDS there is a option to input cell parameters, but sometimes the program 
 would not follow the input values
 and switch back to the one it thinks best. Any suggestions will be 
 appreciated. Thanks!
 
 Best,
 Niu 

Re: [ccp4bb] Fix cell dimensions

[Andrew Leslie]

Dear Niu,

OK, I did not connect this with your earlier Email. If it is 
simply a case of halving one of the cell dimensions, this can be done with 
iMosflm by editing the cell dimensions that come from the indexing step. This 
will not affect the positions of the predictions, but only every second spot 
will be predicted along the cell edge that has been halved. It should be 
perfectly possible to carry out the integration this way. 

I would be surprised if it wasn't possible to do this with other programs.

Best wishes,

Andrew

On 18 Nov 2013, at 22:03, Niu Tou niutou2...@gmail.com wrote:

 Dear Andrew,
 
 As previously I posted a MR case which has a significant 95% off origin peak, 
 some experts suggested to reprocess the data with cutting one axis to half, 
 from 40A to 20A. I tried HKL2000 and XDS, none of them is willing to give a 
 solution with 20A, even I specify it in XDS script. So I wonder is there any 
 way to force this work to be done. Thanks!
 
 Best,
 Niu 
 
 
 On Mon, Nov 18, 2013 at 4:56 PM, Andrew Leslie and...@mrc-lmb.cam.ac.uk 
 wrote:
 Dear Niu,
 
 It depends on which part of processing you are referring to, 
 i.e. the indexing step or the integration step. In MOSFLM there is no way to 
 enforce cell dimensions during indexing, but providing there is an indexing 
 solution that has cell dimensions close to the ones you want, you can enforce 
 a (slightly) different set of cell dimensions during the integration step. 
 Normally other refined parameters will ensure that you still get a good 
 prediction of spot positions.
 
 I suspect that this can be done in other programs too.
 
 Without knowing why you want to do this, I cannot comment on whether this is 
 the best procedure to follow.
 
 Best wishes,
 
 Andrew
 
 
 
 On 18 Nov 2013, at 21:48, Niu Tou niutou2...@gmail.com wrote:
 
  Dear All,
 
  Does any one know how to strictly fix the cell dimensions during data 
  processing? In HKL2000 there is only a keyword to define the longest 
  vector. In XDS there is a option to input cell parameters, but sometimes 
  the program would not follow the input values
  and switch back to the one it thinks best. Any suggestions will be 
  appreciated. Thanks!
 
  Best,
  Niu
 
 

Re: [ccp4bb] TLS group assignment near poorly ordered loop

[Andrew Leslie]

Hi Robbie,

 I was interested in a couple of things in your response:

1. Slightly different boundaries giving surprisingly different results.

Doesn't this suggest that the system is too poorly determined to justify using 
TLS (and there is the issue that Ethan Merritt has raised many times about the 
problems at the junctions of TLS groups).

2. Getting very large differences in B-factors of connected atoms.

I have not seen this problem using refmac, although I have seen it on several 
occasions when structures are refined with PHENIX refine, especially at lowish 
resolution. Quite possibly there are PHENIX parameters that one can change to 
minimise this effect (apart from using one B-factor for a group of atoms), I'm 
not sufficiently familiar with the program.

I think that I would personally go for option 3, as the anisotropy may well be 
different for the different conformities that the loop can adopt, and in any 
case it sounds as if it is not sufficiently well determined to justify adding 
parameters.

However, as you suggest, the best thing is probably to try all options and see 
if the data can really discriminate between them.

Cheers,

Andrew


On 21 Aug 2013, at 22:14, Robbie Joosten robbie_joos...@hotmail.com wrote:

 Hi Shane,
 
 Option one and two may both work. The extra group is not a problem unless it
 doesn't actually improve the fit with the data much. If you really have very
 little data, you should consider first using one overall residual B-factor
 and try to get the most out of the TLS. You can try refining with slightly
 different boundaries for the loop and then use the Parvati server to see
 which gives the most sensible results. They can be surprisingly different.
 Option three has can give unlikely results such as very large differences in
 B-factors of connected atoms. It may give nice results (try and see), but
 option 1 and 2 will probably work much better.
 
 Cheers,
 Robbie
 
 
 -Original Message-
 From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
 Shane Caldwell
 Sent: Wednesday, August 21, 2013 22:44
 To: CCP4BB@JISCMAIL.AC.UK
 Subject: [ccp4bb] TLS group assignment near poorly ordered loop
 
 Hi bb,
 
 
 I have a question about TLS group assignment. I have a loop that is poorly
 ordered. The backbone can still mostly be built, though that's probably
 just
 the predominant conformation of many. TLSMD usually assigns a group
 border on one or both sides of this loop, though the assignment isn't
 always
 consistent. Given that I know the loop is poorly ordered, it might not be
 appropriate to allow it to share TLS parameters with the adjacent well-
 ordered regions. The way I see it, there are 3 options:
 
 
 1. Allow the loop to continue to be integrated into a larger TLS group
 (probably not ideal)
 
 2. Assign the loop it's own TLS group
 
 3. Omit the loop from TLS assignment entirely (i.e. skip those residues in
 the
 .tlsin file)
 
 
 (2) seems the most reasonable to me, but introduces more parameters that
 probably aren't meaningful and may contribute to overfitting. On the other
 hand, I don't know if (3) is scientifically sound and/or will lead to
 problems
 refining in refmac. What would be my best option?
 
 
 Interested to hear thoughts on this, thanks!
 
 Shane Caldwell
 
 McGill University

Re: [ccp4bb] mmCIF as working format?

[Andrew Leslie]

Hi Tim,

   I just downloaded GroEL entry 4KI8 in pdb format and cid format from 
RSCB. The PDB format was 4.7Mb and the CIF format was 5.9Mb, doesn't seem such 
a big difference to me ?  Which example were you looking at ?

Andrew


On 5 Aug 2013, at 09:03, Tim Gruene t...@shelx.uni-ac.gwdg.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Dear all,
 
 having read Gerard Kleywegt's latest announcement on the wwPDB Workshop
 (1st August) made me wonder whether it is planned to introduce mmCIF as
 working format to users in addition to using it at e.g. the PDB, because
 I think that would make life unnecessarily complicated.
 
 The example mmCIF file for GroEL is about 7.5 times bigger than its PDB
 file.
 I know that disk space is 'cheap' nowadays, but that does not make it fast.
 
 And personally I find mmCIF very awkward to work with, since it is not
 line-oriented. 'grep', 'awk', 'perl' etc. do not work well on XML-like
 files.
 Instead of using mmCIF, one could, e.g. introduce a free format PDB
 format, with space holders for non-assigned entities, and maybe a line
 continuation character.
 
 If mmCIF is not going to be the working format for MX (refinement)
 programs I would be happy for a reassurance, and otherwise I would
 appreciate some comments about the benefits of an XML file format over a
 line-oriented free format for the scientists that work with structural data.
 I my opinion, using XML (or mmCIF) for structural information is an
 attempt of programmers to make themselves more indespensable to
 scientists, rather than scientifically needed.
 
 Best,
 Tim
 
 - -- 
 - --
 Dr Tim Gruene
 Institut fuer anorganische Chemie
 Tammannstr. 4
 D-37077 Goettingen
 
 GPG Key ID = A46BEE1A
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.14 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iD8DBQFR/1xbUxlJ7aRr7hoRAkLNAKClH9RpAA7NJsH3YFOTguOo9kjwoQCZAf/m
 JF1oyJNuq+8b+VsywDupElo=
 =bvb3
 -END PGP SIGNATURE-

Re: [ccp4bb] delete reflections with negative peak profile correlation

[Andrew Leslie]

Dear Rain,

   I will let XDS expert users provide the definitive response 
to this because I'm not certain what exactly a negative peak profile 
correlation indicates. However, I would be very cautious about deleting 
reflections simply to improve the reported statistics. Taken to extremes, this 
could lead to a suggestion to reject reflections which have a very poor 
agreement with a model Fcalc to improve the Rfactors for refinement !

There needs to be a good physical reason for rejecting measurements. All the 
software packages make an attempt to remove outliers, but judging what exactly 
constitutes an outlier is far from trivial (one case that is straightforward is 
when the backstop shadow has not been masked correctly during integration and 
one measurement is OK while its symmetry mate is behind the shadow, so there is 
a good physical explanation, but in many cases things are not so obvious).

What one needs to be very careful about is introducing bias. If there are, for 
example, two symmetry related reflections, where because of genuine noise one 
intensity is measured to be weaker than the other and you reject that weaker 
observation, then you are biasing the intensity for that reflection towards the 
larger value.

Simply reducing Rmeas and increasing I/sigmaI is absolutely not a guarantee 
that the resulting dataset is actually better.

Andrew

On 31 Jul 2013, at 03:00, Rain Field rainfiel...@163.com wrote:

 Hi All,
 Inspired by the micro diffraction assembly methods (see 
 http://www.nature.com/nature/journal/vaop/ncurrent/full/nature12357.html), I 
 checked one XDS_ASCII.HKL file and found many reflections has negative peak 
 profile correlation. After deleted them and rerun XSCALE, I/sigma is higher 
 and Rmeas is lower in the same high resolution shell than without deletion. 
 I am wondering why it's not a common practice to delete those reflections?
 Thanks!

Re: [ccp4bb] Split Crystal Dataprocessing

[Andrew Leslie]

It turns out that these images contain two distinct lattices, separated by a 
rotation of about 5 degrees. Using the development version of iMosflm the two 
lattices can be easily indexed and integrated. However, the data is quite 
incomplete due to severe radiation damage.

Andrew 

On 2 Jul 2013, at 15:43, RHYS GRINTER r.grinte...@research.gla.ac.uk wrote:

 Hi All,
 
 I collected some data on the weekend on forked crystal, I collected data on 
 this crystal at the base before the crystal split into two.
 The crystal didn't stand up well to the radiation damage so I shot a number 
 of places along the crystal and got maybe 45 degrees of good data per 
 position. Auto-processing failed on all but one data set, this dataset 
 processed to 3.99 A, but only with around 80% completeness. However looking 
 at the diffraction images I see spots in the first 45 degrees to at least 3.2 
 angstroms. 
 
 I tried quickly to manually process in mosflm, but I noticed that many of the 
 spots appear to be in fact made up to two very closely located spots. This 
 data was collected at a micro-focus station so it was impossible to tell this 
 without careful analysis of the spots. I guess these spots are an indication 
 that the lattice was splitting even at this point.
 
 As a relative novice at data processing, I'm wondering if this kind of data 
 is processable and if so what is the best strategy (or if I should just get 
 back to the bench and grow some more crystals) and program to use?
 
 Cheers,
 
 Rhys

Re: [ccp4bb] ctruncate bug?

[Andrew Leslie]

The integration programs report a negative intensity simply because that is the 
observation. 

Because of noise in the Xray background, in a large sample of intensity 
estimates for reflections whose true intensity is very very small one will 
inevitably get some measurements that are negative. These must not be rejected 
because this will lead to bias (because some of these intensities for symmetry 
mates will be estimated too large rather than too small). It is not unusual for 
the intensity to remain negative even after averaging symmetry mates.

Andrew


On 20 Jun 2013, at 11:49, Douglas Theobald dtheob...@brandeis.edu wrote:

 Seems to me that the negative Is should be dealt with early on, in the 
 integration step.  Why exactly do integration programs report negative Is to 
 begin with?
 
 
 On Jun 20, 2013, at 12:45 PM, Dom Bellini dom.bell...@diamond.ac.uk wrote:
 
 Wouldnt be possible to take advantage of negative Is to extrapolate/estimate 
 the decay of scattering background (kind of Wilson plot of background 
 scattering) to flat out the background and push all the Is to positive 
 values?
 
 More of a question rather than a suggestion ...
 
 D
 
 
 
 From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Ian 
 Tickle
 Sent: 20 June 2013 17:34
 To: ccp4bb
 Subject: Re: [ccp4bb] ctruncate bug?
 
 Yes higher R factors is the usual reason people don't like I-based 
 refinement!
 
 Anyway, refining against Is doesn't solve the problem, it only postpones it: 
 you still need the Fs for maps! (though errors in Fs may be less critical 
 then).
 -- Ian
 
 On 20 June 2013 17:20, Dale Tronrud 
 det...@uoxray.uoregon.edumailto:det...@uoxray.uoregon.edu wrote:
  If you are refining against F's you have to find some way to avoid
 calculating the square root of a negative number.  That is why people
 have historically rejected negative I's and why Truncate and cTruncate
 were invented.
 
  When refining against I, the calculation of (Iobs - Icalc)^2 couldn't
 care less if Iobs happens to be negative.
 
  As for why people still refine against F...  When I was distributing
 a refinement package it could refine against I but no one wanted to do
 that.  The R values ended up higher, but they were looking at R
 values calculated from F's.  Of course the F based R values are lower
 when you refine against F's, that means nothing.
 
  If we could get the PDB to report both the F and I based R values
 for all models maybe we could get a start toward moving to intensity
 refinement.
 
 Dale Tronrud
 
 
 On 06/20/2013 09:06 AM, Douglas Theobald wrote:
 Just trying to understand the basic issues here.  How could refining 
 directly against intensities solve the fundamental problem of negative 
 intensity values?
 
 
 On Jun 20, 2013, at 11:34 AM, Bernhard Rupp 
 hofkristall...@gmail.commailto:hofkristall...@gmail.com wrote:
 As a maybe better alternative, we should (once again) consider to refine 
 against intensities (and I guess George Sheldrick would agree here).
 
 I have a simple question - what exactly, short of some sort of historic 
 inertia (or memory lapse), is the reason NOT to refine against intensities?
 
 Best, BR
 
 
 
 
 -- 
 
 This e-mail and any attachments may contain confidential, copyright and or 
 privileged material, and are for the use of the intended addressee only. If 
 you are not the intended addressee or an authorised recipient of the 
 addressee please notify us of receipt by returning the e-mail and do not 
 use, copy, retain, distribute or disclose the information in or attached to 
 the e-mail.
 
 Any opinions expressed within this e-mail are those of the individual and 
 not necessarily of Diamond Light Source Ltd. 
 
 Diamond Light Source Ltd. cannot guarantee that this e-mail or any 
 attachments are free from viruses and we cannot accept liability for any 
 damage which you may sustain as a result of software viruses which may be 
 transmitted in or with the message.
 
 Diamond Light Source Limited (company no. 4375679). Registered in England 
 and Wales with its registered office at Diamond House, Harwell Science and 
 Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
 
 
 
 
 
 
 
 
 

Re: [ccp4bb] Concerns about statistics

[Andrew Leslie]

Hi Boaz,

The improvement you see in the cofactor geometry after inclusion of higher 
resolution data is very interesting, but is it possible that this is a 
secondary effect resulting from the additional Xray data changing the 
relative weighting of the Xray and stereochemical terms in the refinement ? 

Could you get a similar geometry improvement simply by changing the relative 
weighting (using only the original data)  or would this only be with a penalty 
in other statistics ?

Did you quantify the improvement in the cofactor density, for example by a 
correlation coefficient ?

Cheers,

Andrew


On 14 Jun 2013, at 13:45, Boaz Shaanan bshaa...@exchange.bgu.ac.il wrote:

 In their paper K  D monitored the electron  density for their coffactor and 
 could verify that adding higher resolution shells based on the CC1/2 
 statistics improved the way it looked. I'm not sure they monitored 
 bond-distances and/or esd's but those may well have been affected by 
 restraints and weights anyway, in the reoslution they worked (~1.45 A?). It 
 might be more difficult to judge the effect of including higher resolution 
 shells if there isn't a feature that is easy to monitor as you increase the 
 resolution. In one of the cases that I'm working on I certainly noticed 
 better geometry and e.d. for the co-factor upon adding (somewhat) higher 
 resolution shells. 
 
 Cheers,
 
   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 Steiner, 
 Roberto [roberto.stei...@kcl.ac.uk]
 Sent: Friday, June 14, 2013 12:58 PM
 To: CCP4BB@JISCMAIL.AC.UK
 Subject: Re: [ccp4bb] Concerns about statistics
 
 BTW there's a also an earlier paper (properly cited in Karplus  Diederichs 
 2012) showing the benefit of weak 'high-resolution' reflections.
 
 Acta Crystallogr D Biol Crystallogr. 2010 Sep;66(Pt 9):988-1000. doi: 
 10.1107/S0907444910029938. Epub 2010 Aug 13.
 Inclusion of weak high-resolution X-ray data for improvement of a group II 
 intron structure.
 Wang J.
 Department of Molecular Biophysics and Biochemistry, Yale University, New 
 Haven, CT 06520, USA. jimin.w...@yale.edu
 
 Abstract
 It is common to report the resolution of a macromolecular structure with the 
 highest resolution shell having an averaged I/sigma(I)  or = 2. Data beyond 
 the resolution thus defined are weak and often poorly measured. The exclusion 
 of these weak data may improve the apparent statistics and also leads to 
 claims of lower resolutions that give some leniency in the acceptable quality 
 of refined models. However, the inclusion of these data can provide 
 additional strong constraints on atomic models during structure refinement 
 and thus help to correct errors in the original models, as has recently been 
 demonstrated for a protein structure. Here, an improved group II intron 
 structure is reported arising from the inclusion of these data, which helped 
 to define more accurate solvent models for density modification during 
 experimental phasing steps. With the improved resolution and accuracy of the 
 experimental phases, extensive revisions were made to the original models 
 such that the correct tertiary interactions of the group II intron that are 
 essential for understanding the chemistry of this ribozyme could be described.
 
 Best wishes
 Roberto
 
 On 14 Jun 2013, at 10:43, Dirk Kostrewa kostr...@genzentrum.lmu.de
 wrote:
 
 Dear Andrea,
 
 I agree with Tim and still cut the resolution at I/sigma=2. In my 
 experience, including higher resolution shells with poorer signal-to-noise 
 never changed the apparent resolution of the electron density maps.
 In addition, the high resolution limit at I/sigma=2 coincides very well 
 with the point where the Fo vs. Fo +Gauss(0,1)*sigma(Fo) correlation 
 coefficient curve, reported by BUSTER, crosses the recommended lower limit 
 of 0.9.
 
 And please note, CC*=0.5 corresponds to CC(1/2)=0.143. In my very limited 
 experience, I/sigma=2 corresponds to roughly CC(1/2)~0.7.
 
 Although I'm very excited about the CC(1/2) or CC* paper by Karplus  
 Diederichs, I still prefer to be on the save side, until it has been 
 verified in numerous cases, that choosing high resolution cutoffs based on 
 CC(1/2) really leads to higher resolution structures. The recommended 
 procedure to include small resolution increments in refinement to decide the 
 high resolution cutoff is very time-consuming.
 
 Best regards,
 
 Dirk.
 
 
 Am 13.06.13 17:15, schrieb Andrea Edwards:
 Hello group,
 I have some rather (embarrassingly) basic questions to ask. Mainly.. when 
 deciding the resolution limit, which statistics are the most important? I 
 have always been taught that the highest resolution bin should be 

Re: [ccp4bb] why not read mmcif cell if rpesent?

[A Leslie]

Hi Bernhard,


 When I have used the convert program via ccp4i, the cell and  
symmetry have indeed been read from the mmcif file and written to the  
MTZ file.


Andrew


On 16 May 2013, at 13:50, Bernhard Rupp wrote:


Dear Developers,
I wonder if there is any particular reason why, if present in an  
mmcif, cell parameters and SG

are not read from the mmcif file when using ‘convert to mtz’?

Best, BR

Re: [ccp4bb] why not read mmcif cell if rpesent?

[A Leslie]

Yes, this is indeed what I see as well and it confused me too ...  
those fields should not be orange highlighted according to my  
understanding of the way CCP4i works.


Andrew


On 16 May 2013, at 14:33, Bernhard Rupp wrote:

Ah – let me rephrase that – cif2mtz ultimately seems to read them,  
but the GUI does not populate the corresponding fields. Normally I  
thought an orange highlighted field is a mandatory field that needs  
some data…


Windows ccp4 6.3.0-020 updated

Best, BR

From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf  
Of A Leslie

Sent: Thursday, May 16, 2013 3:10 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] why not read mmcif cell if rpesent?

Hi Bernhard,


 When I have used the convert program via ccp4i, the cell and  
symmetry have indeed been read from the mmcif file and written to  
the MTZ file.


Andrew


On 16 May 2013, at 13:50, Bernhard Rupp wrote:


Dear Developers,
I wonder if there is any particular reason why, if present in an  
mmcif, cell parameters and SG

are not read from the mmcif file when using ‘convert to mtz’?

Best, BR


no_cell.gif

Re: [ccp4bb] vitrification vs freezing

[A Leslie]

Dear Sebastiano,

   This is not entirely straight-forward.  
The Oxford English dictionary gives the first definition of freeze  
relevant to this discussion as:
Of (a body of) water: be converted into or become covered with ice  
through loss of heat


This is certainly not what we want to do to our crystals.

However, another definition in OED is:
Cause (a liquid) to solidify by removal of heat, suggesting that  
this does not necessarily mean the formation of crystals.


The Larousse Dictionary of Science and Technology (1995) has the  
following definition:
Freeze-drying (Biol.) A method of fixing tissues sufficiently rapidly  
as to inhibit the formation of ice-crystals.


The Dictionary of Microbiology and Molecular Biology (3rd Ed) in the  
entry on Freezing has the sentence:
Rapid freezing tends to prevent the ice crystal formation by  
encouraging vitrification.


Both of these erstwhile volumes therefore suggest that freezing does  
not necessarily imply the formation of crystals. However, the term is  
ambiguous, while vitrification is not.


Personally I use cryocooled instead.

Best wishes,

Andrew



On 15 Nov 2012, at 17:13, Sebastiano Pasqualato wrote:



Hi folks,
I have recently received a comment on a paper, in which referee #1  
(excellent referee, btw!) commented like this:


crystals were vitrified rather than frozen.

These were crystals grew in ca. 2.5 M sodium malonate, directly dip  
in liquid nitrogen prior to data collection at 100 K.
We stated in the methods section that crystals were frozen in  
liquid nitrogen, as I always did.


After a little googling it looks like I've always been wrong, and  
what we are always doing is doing is actually vitrifying the crystals.
Should I always use this statement, from now on, or are there  
english/physics subtleties that I'm not grasping?


Thanks a lot,
ciao,
s


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

tel +39 02 9437 5167
fax +39 02 9437 5990

please note the change in email address!
sebastiano.pasqual...@ieo.eu

Re: [ccp4bb] Indexing with XDS

[A Leslie]

Dear Theresa

In response to your first question, one way to do this is to look  
closely at the image (eg changing the contrast level) with the  
predicted pattern superimposed after indexing, or alternatively just  
integrate the image and look at the reported mean I/sigmaI as a  
function of resolution. Both of these  are trivially easy to do with  
iMosflm.


You need to remember that any number of issues (eg zingers, hot  
pixels, ice diffraction) can give rise to what are apparently  
significant intensity spots, so to distinguish between real  
diffraction and artifacts you need to look carefully at the spot size  
and shape as well as its intensity (and whether it is predicted).


The other point to bear in mind is that generally there is no problem  
integrating the images to a resolution a bit beyond where spots are  
visible, eg to 3.0-3.2Å when spots are only visible to ~3.4-3.5Å and  
then using the merging or refinement statistics to decide the true  
resolution of the data.


Best wishes,

Andrew Leslie

On 8 Oct 2012, at 23:36, Theresa Hsu wrote:


Dear all

I took some images from test crystal and tried to index them to get  
cell parameters, not enough for structure solution. I can see spots  
at 3.5 A with ADXV but when I indexed, XDS reports up to 3.0 A in  
INCLUDE_RESOLUTION_RANGE in XDS_ASCII.HKL.


Questions:

1. How do I know that the spot at 3.0 is not background noise?
2. What is the function of FRAME.cbf file?

Thank you.

Theresa

Re: [ccp4bb] imosflm background definition

[A Leslie]

Hi Andreas,

  The simple answer to this is that you do NOT  
attempt to redefine the background. Providing the additional spots  
shown in your image belong to the same lattice, mosflm will  
automatically exclude pixels from adjacent spots when doing the  
background plane fitting, so you need do nothing. It helps to have a  
larger box size because the background plane is better defined.



To answer your question, you need to go to Settings - Processing  
Options - Advanced integration  in imosflm, then the top 5 lines  
define the measurement box parameters, changing the box width and  
height should do what you want, although you may need to uncheck the  
box Optimise overall box size to stop the box being made bigger again.


Best wishes,

Andrew





On 17 Sep 2012, at 15:03, Andreas Förster wrote:


Hi all,

I'm integrating data from a crystal with a fairly long axis.  In  
iMosflm (1.0.7), the background definition is so generous that  
plenty of pixels from adjacent peaks are included (see attached).   
Can someone tell me how I redefine the background to be tighter  
around the spots?


Thanks.


Andreas


--
   Andreas Förster, Research Associate
   Paul Freemont  Xiaodong Zhang Labs
Department of Biochemistry, Imperial College London
   http://www.msf.bio.ic.ac.uk
backgroundSpots.png

Re: [ccp4bb] Aimless and Pointless

[A Leslie]

It is possible to force Pointless to select a particular solution,  
using the Find or match Laue group option in CCP4i. The default  
option here is Determine Laue group but if you select the Choose a  
previous solution checkbox you can specify the solution you want  
Pointless to select, by Space group name, Laue group name or Laue  
group solution number (from a previous run).


You can do the same with the Symmetry, Scale, Merge (Aimless) if you  
check the tickbox Customise symmetry determination and then Choose  
a previous solution.


In cases of pseudosymmetry it is sometimes necessary to override the  
solution Pointless thinks is best.


Andrew



On 12 Sep 2012, at 23:41, Cosmo Z Buffalo wrote:


Hi all,

I am currently trying to perform a quickscale in iMosflm 7.0.9 after  
I integrate in an R 32 space group.  Unfortunately, both Pointless  
and Aimless are both giving me a best solution space group of P 43 3  
2.  After analyzing the statistics, this cannot be correct.  Other  
programs such as HKL2000 have confirmed this to be true.  So my  
question: is it possible to force Aimless and Pointless to generate  
statistics in a space group other than the one it predicts?  And if  
so, how would I do this?


-Cosmo

[ccp4bb] Problem with indexing in the latest iMosflm release

[A Leslie]

There is a significant problem that affects the autoindexing in the  
latest release of iMosflm (Version 1.0.6, March 2012).


The indexing solutions themselves are not affected, but the suggested  
solution (highlighted in blue) will, in some cases, be a solution with  
a higher symmetry than the true solution. This will be indicated by  
the fact that the penalty for the suggested solution will be  
significantly higher than for lower symmetry solutions.


An example is shown below, where iMosflm is suggesting the  
orthorhombic face centred solution (number 6, oF) which has a penalty  
of 20, while the correct solution is in fact the C face centred  
monoclinic  solution (number 2). This happens because of a bug in the  
code and because the rms error on spot positions (sigma(x,y)) for the  
oF solution is not much higher than that for the triclinic solution.


Therefore the solution suggested by the latest iMosflm release needs  
to be examined critically. In the example below, the jump in penalty  
in going from solution 2 (penalty 1) to solution 3 (penalty 15)  
strongly suggests that the correct solution is number 2.


Indexing in background jobs with ipmosflm is not affected  by this  
error.


Apologies to all those that have downloaded this new version. A bug  
release, that corrects this problem, will be available soon.



Thanks to Frank von Delft for bringing this to our attention, mea culpa.


Andrew Leslie



inline: indexing_solution_failure.tiff

Re: [ccp4bb] unique reflections vs unique observations

[Andrew Leslie]

Dear Naveed,

   The situation can indeed be a bit confusing. The term
observations is actually used with two different senses in
SCALA. The first is in text such as the following:

 Number of observations read  :62154
 Number of unique reflections read: 5108
 Number of observations output: 4922
 Number of outliers rejected  :   26
 Number of observations rejected on Emax limit:0
 Number of observations outside resolution limits :0
   (observations outside resolution limits are omitted from the output file)

In this case, each part of a partially recorded reflection (those that
span several images) is counted as a separate observation, so for example
if a reflection spans 3 images it will have 3 observation.

However, in the summary at the end of SCALA it gives:
   Overall  InnerShell  OuterShell

  Total number of observations   23342   759  2493
  Total number unique 4922   173   546

This is from the same logfile, but here the total number of observations
is AFTER the components of partials have been added together, so the
number is smaller. However the number of unique reflections is the same.

Typically, number of observations refers to this latter number rather
than the former. In a typical Table 1, the number of reflections would
be the number of unique reflections (ie after merging symmetry mates)
while I feel that the number of observations should be reserved for the
total number of reflections measured (before merging symmetry mates). Very
often the multiplicity is also given in Table 1, which allows a rough
estimate of the total number of observations if this is not given
explicitly.

Note also that some reflections output by SCALA can be rejected at the
TRUNCATE step (those that are too negative and possibly E value
outliers, although the latter are normally rejected by SCALA). Thus the
number you see in the MTZ file as used by REFMAC may have fewer
reflections than those reported by SCALA as unique reflections.

Strictly speaking, the Number of reflections in Table 1 should be those
output by TRUNCATE (if used) rather than those reported in the SCALA
logfile, but I think many people use the value given by SCALA.

I hope this helps clarify things a bit.

Best wishes,

Andrew Leslie











 Dear CCP4 users,

 I am a bit confused about the use of these terms in regards to structure
 refinement statistics. When I process my data with SCALA, the program
 outputs statistics in terms of total and unique numbers of observations.
 However, when I use the MTZ files with REFMAC, the final PDB file has
 number of reflections. These values are of similar magnitude, but not
 identical. The issue is even more complicated when I look at tables of
 statistics between different journals. Authors often report unique
 reflections or unique observations.

 My questions are:

 1) Are these two terms interchangable?
 2) Are they relevant to the different stages of processing (e.g. data
 collection vs structure refinement)?
 3) How do I rationalize the difference between the two values?

 I have read some of the widely used textbooks, but I am still confused
 when looking at publications. Any comments would be highly appreciated!

 Kind regards,

 Naveed Nadvi

 Faculty of Pharmacy,
 University of Sydney.

Re: [ccp4bb] Defining beamstop and error during indexing- moslfm

[Andrew Leslie]

Dear Sonali,

Just to add to Tim's reply, when you open the image with
iMosflm, you can Drag and drop the direct beam position in the
image display window. First, you have to click on the leftmost
icon in the row of icons under the image filename (a green
cross) which will display the direct beam position as read
from the image header as a green cross on the image. You can
then drag then over to where you think the beam position
should be (judging from the position of the backstop shadow).

If indexing still does not work, you can try doing a direct beam search
from the indexing pane, which will do a grid search +/- 2mm from the
current position.

However, you need to beware of one thing. I believe that the rotation axis
 on the Sercat beamline goes in the opposite direction to most beam lines.
In such cases, indexing using more than one image will never work, because
the relative phi values will be wrong. You can try indexing with one
image, and then if that works, try predicting the next image. If that
prediction does not match, it is almost certainly because the rotation
direction is wrong.

To deal with this, choose the Settings-Experiment settings menu and click
on the reverse phi box. Then you MUST repeat the spot search for each
image being used in indexing, then it should all work.

Best wishes,

Andrew

 Dear All,

 We have collected a data for a protein crystal at SER-CAT Chicago and the
 detector is mar300.We are using mosflm to process the data.While
 indexing,  the beamstop which it is taking is wrong, due to which it
 fails.

 I am trying to define the beamstop manually using tools like mask and spot
 search area.
 (it might be wrong)
 It will be highly appreciable if someone can please suggest if this the
 method we should use to define the beamstop or there is any site
  definition file which has to be used, as it is available for HKL2000 or
 how we have to define the beamstop in mosflm.



 --
 Sonali Dhindwal

 “Live as if you were to die tomorrow. Learn as if you were to live
 forever.”

Re: [ccp4bb] Defining beamstop and error during indexing- moslfm

[Andrew Leslie]

Hi Sonali,

 How did you assign the spacegroup ... did you run POINTLESS ?
A table of Rmerge vs resln from SCALA would be helpful in addition to a
screen shot of an image as Francis suggested.

Andrew

 Dear Andrew and all the people for their help,
 I am providing mosflm the right beamstop and now, I am able to do the
 indexing, refinement and indexing too.Then I run scala for the output mtz
 file and it shows Rmerge too high 0.58and also when examining the spots
 and predictions in the image, it seems like it is not picking a lot of
 spots, so missing  large number of reflections.So, any suggestions to
 correct it or am i doing something wrong.
 Thanks again for the help and suggestions

 --
 Sonali Dhindwal

 “Live as if you were to die tomorrow. Learn as if you were to live
 forever.”

 --- On Thu, 22/3/12, Andrew Leslie and...@mrc-lmb.cam.ac.uk wrote:

 From: Andrew Leslie and...@mrc-lmb.cam.ac.uk
 Subject: Re: [ccp4bb] Defining beamstop and error during indexing- moslfm
 To: CCP4BB@JISCMAIL.AC.UK
 Date: Thursday, 22 March, 2012, 7:43 PM

 Dear Sonali,

             Just to add to Tim's reply, when you open the image with
 iMosflm, you can Drag and drop the direct beam position in the
 image display window. First, you have to click on the leftmost
 icon in the row of icons under the image filename (a green
 cross) which will display the direct beam position as read
 from the image header as a green cross on the image. You can
 then drag then over to where you think the beam position
 should be (judging from the position of the backstop shadow).

 If indexing still does not work, you can try doing a direct beam search
 from the indexing pane, which will do a grid search +/- 2mm from the
 current position.

 However, you need to beware of one thing. I believe that the rotation axis
  on the Sercat beamline goes in the opposite direction to most beam lines.
 In such cases, indexing using more than one image will never work, because
 the relative phi values will be wrong. You can try indexing with one
 image, and then if that works, try predicting the next image. If that
 prediction does not match, it is almost certainly because the rotation
 direction is wrong.

 To deal with this, choose the Settings-Experiment settings menu and click
 on the reverse phi box. Then you MUST repeat the spot search for each
 image being used in indexing, then it should all work.

 Best wishes,

 Andrew

 Dear All,

 We have collected a data for a protein crystal at SER-CAT Chicago and
 the
 detector is mar300.We are using mosflm to process the data.While
 indexing,  the beamstop which it is taking is wrong, due to which it
 fails.

 I am trying to define the beamstop manually using tools like mask and
 spot
 search area.
 (it might be wrong)
 It will be highly appreciable if someone can please suggest if this the
 method we should use to define the beamstop or there is any site
  definition file which has to be used, as it is available for HKL2000
 or
 how we have to define the beamstop in mosflm.



 --
 Sonali Dhindwal

 “Live as if you were to die tomorrow. Learn as if you were to live
 forever.”

Re: [ccp4bb] scala and postref

[A Leslie]

Hi Vijay,

  The obvious person to answer this is Phil Evans, but he  
is in New Zealand at the moment and may well not be reading Emails, so  
you might need to wait until he is back in the UK (1-2 weeks). I know  
that he felt the POSTREF option was not an important one to maintain,  
because post-refinement is carried out in MOSFLM, so I am not very  
surprised that it does not work.


Cheers,

Andrew

On 22 Feb 2012, at 13:51, Vijay Reddy wrote:


Hi all,

Does anyone have version(s) of scala and postref that work together  
in tandem and willing to share. Even older versions of these  
programs are fine with me.


I can not seem to make the recent versions of the programs work  
together... even though there is a POSTREF option available in scala.


Thanks for your consideration.

Regards,
Vijay


Vijay S. Reddy, Ph.D.
Associate Professor
Department of Molecular Biology, TPC6
The Scripps Research Institute,
10550 North Torrey Pines Road,
La Jolla, CA 92037

E-mail: red...@scripps.edu
WWW:http://www.scripps.edu/~reddyv
VIPERdb:http://viperdb.scripps.edu

Phone:(858) 784-8191
FAX:(858) 784-8896

Re: [ccp4bb] choice of wavelength

[A Leslie]

On 15 Feb 2012, at 23:55, Bart Hazes wrote:

Diffracted intensity goes up by the  cube of the wavelength, but so  
does absorption and I don't know exactly about radiation damage. One  
interesting point is that on image plate and CCD detectors the  
signal is also proportional to photon energy, so doubling the  
wavelength gives 8 times diffraction intensity, but only 4 times the  
signal on integrating detectors (assuming the full photon energy is  
captured). So it would be interesting to see how the equation works  
out on the new counting detectors where the signal does not depend  
on photon energy.



You make a good point about the variation in efficiency of the  
detectors, but I don't think your comment about the new counting  
detectors (assuming this refers to hybrid pixel detectors) is  
correct. The efficiency of the Pilatus detector, for example, falls  
off significantly at higher energies simply because the photons are  
not absorbed by the silicon (320  microns thick). The DQE for the  
Pilatus is quoted as 80% at 12KeV but only 50% at 16KeV and I think  
this variation is entirely (or at least mainly) due to the efficiency  
of absorption by the silicon.


Andrew



Another point to take into account is that beamlines can have  
different optimal wavelength ranges. Typically, your beamline guy/ 
gal should be the one to ask. Maybe James Holton will chime in on  
this.


Bart

On 12-02-15 04:21 PM, Jacob Keller wrote:

Well, but there is more scattering with lower energy as well. The
salient parameter should probably be scattering per damage. I  
remember

reading some systematic studies a while back in which wavelength
choice ended up being insignificant, but perhaps there is more info
now, or perhaps I am remembering wrong?

Jacob

On Wed, Feb 15, 2012 at 5:14 PM, Bosch, Juergenjubo...@jhsph.edu   
wrote:
No impact ? Longer wavelength more absorption more damage. But  
between the choices given no problem.
Spread of spots might be better with 1.0 versus 0.9 but that  
depends on your cell and also how big your detector is. Given your  
current resolution none of the mentioned issues are deal breakers.


Jürgen

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

On Feb 15, 2012, at 18:08, Jacob Kellerj-kell...@fsm.northwestern.edu 
  wrote:



I would say the better practice would be to collect higher
multiplicity/completeness, which should have a great impact on  
maps.

Just watch out for radiation damage though. I think the wavelength
will have no impact whatsoever.

JPK

On Wed, Feb 15, 2012 at 4:23 PM, Seungil  
Hanshan06...@gmail.com  wrote:

All,
I am curious to hear what our CCP4 community thoughts are
I have a marginally diffracting protein crystal (3-3.5 Angstrom  
resolution)

and would like to squeeze in a few tenth of angstrom.
Given that I am working on crystal quality improvement, would  
different
wavelengths make any difference in resolution, for example 0.9  
vs. 1.0

Angstrom at synchrotron?
Thanks.
Seungil



Seungil Han, Ph.D.

Pfizer Inc.

Eastern Point Road, MS8118W-228

Groton, CT 06340

Tel: 860-686-1788,  Fax: 860-686-2095

Email: seungil@pfizer.com





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

Re: [ccp4bb] (i)mosflm indexing / cell refinement

[A Leslie]

Dear Bryan,

 As Mark van Raaij pointed out you have complete  
flexibility in specifying the images to be used in autoindexing or in  
cell refinement.


However, the default behaviour is to use the first image and a second  
image that is as close as possible to 90 degrees away for  
autoindexing, and for cell refinement a small wedge of data starting  
with the first image and a second small wedge as close as possible to  
90 degrees away. In more recent versions, three or four wedges will be  
selected for cell refinement in low symmetry space groups (monoclinic / 
triclinic using images at 0, 90 and one or 2 wedges in between) as  
this gives better determined parameters.


The use of two images (or sets of images) well separated in phi  
(ideally 90 degrees) allows the most reliable determination of the  
cell parameters, especially for low symmetry space groups. In  
particular, for monoclinic or triclinic space groups, when using a  
single image it is possible to obtain an indexing solution that  
predicts that image very well but is in fact incorrect, and will not  
predict images far away in phi.


Best wishes,

Andrew






On 17 Mar 2011, at 18:44, Bryan Lepore wrote:


I seem to have noticed that (i)mosflm can index on one image, or two
images that are not related by 90 degrees. also, cell refinement
sometimes splits up a set of frames into maybe 3 or four segments of
e.g. a few degrees each. and of course, I can set it based on frames
90 degrees apart.

reason I ask is that i thought mosflm's modus operandi was based on
frames in general being related by 90 degrees - is mosflm simply
written differently or is there some criteria it uses to make these
settings, or something else...

-Bryan

[ccp4bb] Generating a PDB file for a known ligand

[A Leslie]

Dear All,

I simply want to create a PDB file for adenosine from the existing  
monomer library entry ADN.cif. Normally I do this using COOT (get  
monomer) but when I try this I get the following error:


: _lib_update   12/05/10
:  --
:  ERROR: number of monomers   3000 /lib. limit/
:  Change parameter MAXMLIST in lib_com.fh
exit status: 0
INFO:: libcheck status: 0
libcheck failed to write the output cif file.


I then try using LIBCHECK standalone to get the PDB file. I get the  
same error if I use the FILE_CIF input keyword and give it the  
filename for ADN.cif, no surprise, as this is (I assume) what COOT does.


I then copy over ADN.cif to my local directory, run LIBCHECK again and  
use the FILE_L keyword to specify the (local) ADN.cif file. I then get  
the error:


  ERR: item _chem_comp_tree.atom_id :O2'  not found in the atom list
  MON,BLOCK :ADN data_comp_ADN

suggesting that there is an error in ADN.cif !

I know that I should really correct the dimension error that I first  
got in COOT, but Phil Evans looks after our CCP4 installation and he  
is away and I'm not sure where to start.


Does anyone understand why using FILE_L command does not work, or  
indeed any other way that I can produce the PDB file from the cif file ?


Thanks

Andrew

Re: [ccp4bb] Generating a PDB file for a known ligand

[A Leslie]

Hi Ian,

This is bizarre, we also have 6.1.13 installed here, but in my ADN.cif  
(dated Oct 29 2008) the atom names have primes, but are surrounded by  
quotes which I think allows a mechanism for them to be converted to a  
* if you have the appropriate changes listed in your (personal) library.


I don't understand why these differ (unless Phil change the ADN.cif  
entry here for some reason).


I think we need a comment for the library people !

Cheers

Andrew


On 15 Mar 2011, at 14:23, Ian Clifton wrote:


On 15/03/11 12:57, A Leslie wrote:
…


I then try using LIBCHECK standalone to get the PDB file. I get the
same error if I use the FILE_CIF input keyword and give it the
filename for ADN.cif, no surprise, as this is (I assume) what COOT  
does.


I then copy over ADN.cif to my local directory, run LIBCHECK again  
and
use the FILE_L keyword to specify the (local) ADN.cif file. I then  
get

the error:

  ERR: item _chem_comp_tree.atom_id :O2'  not found in the atom list
  MON,BLOCK :ADN data_comp_ADN

suggesting that there is an error in ADN.cif !



I can’t reproduce this (CCP4-6.1.13), but I’m immediately suspicious  
of

the apostrophe (U+0027) character in the error message. I’m not a DNA
dabbler, so I can’t help much, but I bet the problem is due to  
“primed”

atom names being replaced by stars, or something else. In my CCP4
distribution, the atom names are starred in the dictionary file for  
ADN.

In official PDB files, they’re primed I think.
--
Best wishes,
Ian.

Re: [ccp4bb] MOSFILM

[Andrew Leslie]

Dear Rex,

As Albert has already pointed out, the latest version is 7.0.7 and can be
downloaded from:

http://www.mrc-lmb.cam.ac.uk/harry/mosflm/

6.2.6 dates from about 2006 I think. It will not deal with Pilatus
detectors and there have been a very large number of improvements since
then.

For ease of use, we would also strongly recommend using the new mosflm
interface (iMosflm) which can be downloaded from the same site.

Best wishes,

Andrew Leslie


 Is MOSFILM 6.2.6 the latest version?
  
 Rex Palmer
 Birkbeck College

Re: [ccp4bb] mosflm gain

[Andrew Leslie]

Dear James,

 Many thanks for the detailed explanation. I do find
your results very interesting  and (when time allows
!) I will certainly investigate this effect in more
detail and see if I find similar results for data
that shows significant levels of radiation damage (as
mine invariably seem to do). I have to admit that it
is not entirely clear to me why PSF would result in a
correlation between SDFAC and SDADD, although this is
clearly what you see. It would be rewarding to get to
the bottom of this. As I mentioned earlier, Phil
Evans is currently looking at the refinement of the
SD parameters in relation to Aimless (the imminent
replacement for SCALA) so he is also very interested
in figuring out exactly what is going on here (but
does not have any answers as yet).

Best wishes,

Andrew


 Andrew!  You don't believe me?  Well, I suppose it serves me right for
 not explaining where the idea came from (see below).

   I do, however, agree with Andrew's assessment that the default-chosen
 gain in MOSFLM is adequate for all practical purposes.  Any error in
 GAIN will be almost exactly compensated for by a corresponding change in
 Sdfac in SCALA, and the final value of sigma(I) will be essentially the
 same.  The only possible difference will be in the sigma-based outlier
 rejection within MOSFLM, but since the typical errors in the sigma are
 only ~30%, I predict it will be hard to find a situation where this
 makes or breaks a structure determination.

 So, by way of explanation: there are three things that led me to this
 conclusion:
 1) the control: fake data with all pixels independent.
  adjusting the GAIN as MOSFLM recommends from the BGRATIO analysis
 does, in fact, reproduce the correct value of the gain used to
 generate the fake data.  In SCALA, Sdfac refines to ~1.0, SdB refines to
 0, and Sdadd refines to the actual magnitude of fractional error
 (introduced by beam flicker, shutter jitter, etc.).  No surprises here.
 2) blur the fake data with the point-spread function (PSF) empirically
 derived for my detector
  In this case, the MOSFLM-refined gain is too low.  In SCALA,
 Sdfac refines to ~1.3, SdB refines to 3-5, and Sdadd is a bit low.
 These parameters are about what I see processing good real data.
 3) use real data, but force MOSFLM to use the GAIN calibrated
 independently for the detector
 MOSFLM grumbles a lot about the BGRATIO.  In SCALA, Sdfac refines to
 ~1, and SdB refines to ~0.  Sdadd is consistent with my
 independently-measured fractional error sources.

 Now, I have not evaluated this approach on a huge number of data sets,
 but in this case the PSF was both necessary and sufficient to explain
 the mystery of SdB.  That is: the need for SdB arises because using an
 incorrect gain creates a correlation between Sdfac and Sdadd.  I
 imagine there are other ways to get a non-zero SdB as well, but for
 good data I suspect this is the dominant mechanism.  I never wrote
 this up because I am fairly certain the article would do nothing to
 improve the impact factor of the journal in which it was published, but
 this anecdote might perhaps be useful to Andrew, Phil, and a few other
 readers of this list.

 -James Holton
 MAD Scientist


 On 3/7/2011 2:00 AM, A Leslie wrote:


 I have to say that I don't fully agree with James' recommendation to
 adjust the GAIN in MOSFLM until the calculated SDFAC parameter in
 SCALA is 1.0.

 (Background information, the sigmas from Mosflm sd(I) are corrected in
 SCALA according to
sd(I) corrected = SdFac * sqrt{sd(I)**2 + SdB*Ihl +
 (SdAdd*Ihl)**2}
 in order to get the best agreement between corrected sigmas and the
 observed differences between symmtery/Friedel related intensities)


 While I fully agree with his argument that systematic errors such as
 absorption, etc give an error proportional to the intensity, and
 therefore should be corrected by the SDADD term rather than SDFAC, in
 any real world data set that I have come across the situation is not
 so simple. Indeed, according to the usual treatment of errors there
 should be no need for the SDB term in SCALA, but in practice it is
 essential to have this term to be able to match corrected sigmas with
 the observed differences between symmetry related reflections. It also
 turns out that the three variable parameters SDFAC, SDB and SDADD are
 highly correlated, so one can get rather different values for any
 individual parameter from very similar datasets. Radiation damage is
 certainly one source of error which would not be expected to follow a
 simple error model, or non-isomorphism if multiple crystals have been
 used.

 Phil Evans is not entirely happy with the behaviour of the refinement
 of these parameters and is in fact currently looking at this, but
 there is a  basic problem here that one is trying to use a simple
 error model for a situation where (for whatever reason) it does not
 really apply.

 The sigma estimates from MOSFLM

Re: [ccp4bb] mosflm gain

[A Leslie]

I have to say that I don't fully agree with James' recommendation to  
adjust the GAIN in MOSFLM until the calculated SDFAC parameter in  
SCALA is 1.0.


(Background information, the sigmas from Mosflm sd(I) are corrected in  
SCALA according to
   sd(I) corrected = SdFac * sqrt{sd(I)**2 + SdB*Ihl +  
(SdAdd*Ihl)**2}
in order to get the best agreement between corrected sigmas and the  
observed differences between symmtery/Friedel related intensities)



While I fully agree with his argument that systematic errors such as  
absorption, etc give an error proportional to the intensity, and  
therefore should be corrected by the SDADD term rather than SDFAC, in  
any real world data set that I have come across the situation is not  
so simple. Indeed, according to the usual treatment of errors there  
should be no need for the SDB term in SCALA, but in practice it is  
essential to have this term to be able to match corrected sigmas with  
the observed differences between symmetry related reflections. It also  
turns out that the three variable parameters SDFAC, SDB and SDADD are  
highly correlated, so one can get rather different values for any  
individual parameter from very similar datasets. Radiation damage is  
certainly one source of error which would not be expected to follow a  
simple error model, or non-isomorphism if multiple crystals have been  
used.


Phil Evans is not entirely happy with the behaviour of the refinement  
of these parameters and is in fact currently looking at this, but  
there is a  basic problem here that one is trying to use a simple  
error model for a situation where (for whatever reason) it does not  
really apply.


The sigma estimates from MOSFLM are only intended to give an estimate  
of the random error in the intensities. In my opinion, trying to  
account for systematic errors is best done at the point of merging the  
data where much more information is available (ie symmetry related  
measurements).


I would be most interested to hear of any examples where the default  
value of the GAIN in MOSFLM is clearly wrong, but to the best of my  
current knowledge the default GAIN is perfectly adequate.


Best wishes

Andrew
On 4 Mar 2011, at 19:47, James Holton wrote:

I have found that the best way to get the GAIN right in MOSFLM is  
to have a look at the optimum Sdfac parameter at the end of SCALA  
(the first of the three SDCORRection values).  Specifically, if  
SDFac is  1, then you need to increase the GAIN.  This is because  
SDFac1 means that the spots were noisier than MOSFLM thought they  
should be, and if a given number of ADU is noisier than expected,  
then there must have been fewer photons involved in generating the  
signal.  This means that the true gain was higher.  Yes, there are  
other sources of error, like shutter jitter, beam flicker,  
calibration errors, absorption effects, scale factor errors, etc.   
But these are all directly proportional to the intensity, and  
therefore accounted for by adjusting SDadd (the last of the three  
SDCORR values).  SDfac accounts for noise proportional to the square  
root of intensity, and only shot noise (like photon counting)  
behaves like that.


David Waterman makes an excellent point that the point-spread  
function (PSF) acts like a smoothing filter and makes the background  
look less noisy than photon-counting error permits.  This makes the  
BGRATIO-estimated GAIN lower than the true GAIN.  However, one can  
argue that this is not always a bad thing, since the error in  
measuring the intensity of a given area of flat background really is  
better than photon counting.  This is because you have the  
smoothing effect of the PSF working for you: bringing in signal  
from areas outside the region you are measuring (prior knowledge of  
flatness if you will).  However, this smoothing effect of the PSF  
does not apply to spots because spot photons all arrive in  
essentially the same place, and no smoothing will change the  
intrinsic noise of the total number of photons that actually  
arrived.  The upshot of this is that we really need two different  
values for GAIN, one for the background and one for the background- 
subtracted spot intensity.  The influence on sigma(I) would depend  
on the relative contributions from the spot vs the background under  
it.  I am pretty sure this is not implemented.


It is perhaps interesting that there is also a third type of noise  
which is independent of the spot intensity: read-out noise.  This  
used to be called fog on film detectors.  Despite all the money we  
spend on detectors that minimize it, there is no specific accounting  
for read-out noise in MOSFLM or any other integration package I am  
aware of.  However, a trick to account for it is to simply lower  
the ADCOFFSET.  For example, using 1 A X-rays on an ADSC Q315r  
detector in hwbin mode, the true GAIN is 1.8 ADU/photon, the  
ADCOFFSET is 40 ADU, and the read-out noise is equivalent 

Re: [ccp4bb] mosflm gain

[A Leslie]

Dear Bryan,

The quick answer is no. As David Waterman  
mentioned, it has a default value for the gain for each type of  
detector that it can deal with.


A more detailed answer. An incorrect value for the gain can be  
indicated by values of the BGRATIO which differ significantly from  
unity (1.0). BGRATIO  is the ratio of the rms variation in the  
background to the variation expected on the basis of Poisson  
statistics, using the gain to convert from digitised values in the  
image to X-ray photons. This is calculated for all measured spots, and  
binned as a function of intensity for each image measured (and printed  
in the full logfile). Mosflm prints a warning message if this differs  
from 1.0 by more than 10% and will suggest an improved value for the  
gain that should be used.


There are a host of caveats in this procedure. For example, if the  
images contains significant diffuse scatter around the Bragg spots,  
the BGRATIO may be above 1.0 ... this is probably the commonest  
effect, but does not mean the gain is wrong. If for any reason the  
mask definition (defining the boundary between background and spot)  
has not worked correctly so the spot extends into the background, this  
will also give a BGRATIO of one (in this case, the BGRATIO will tend  
to be close to 1.0 for weak spots but greater than 1.0 for strong  
ones). The boundary is controlled by the Profile tolerance  
parameters, which are sometimes set artificially high to help process  
images where the spots are not fully resolved.


This is why Mosflm does not automatically update its default value for  
the gain based on the BGRATIO.


As David has mentioned, this procedure also assumes that adjacent  
pixels are independent, which they most certainly are not (except  
possibly for some pixel detectors), due to the point spread function  
of the detectors and corrections that are applied to the raw images.


Does it matter ? The gain is used to identify outliers in the  
background plane determination (eg due to zingers, shadows, ice spots,  
hot pixels etc) which are rejected from the calculation, so if it is  
significantly in error this will introduce systematic errors in the  
integrated intensities. This can show up in the cumulative intensity  
distribution in Truncate if the gain is a very long way off. I have  
not done a proper study of this, but I think it would need to be out  
by more than 20% to have a significant effect. The gain is also used  
to calculate sig(I), however, the sig(I) values from Mosflm are  
adjusted in SCALA to reflect the true variation between symmetry  
related reflections so that providing the multiplicity is high enough  
for this to work correctly this will not have any real effect on the  
final merged data.


The bottom line is that the estimates for sig(I) that emerge for this  
procedure seem to be quite good, in that the correction factors that  
are subsequently applied in SCALA for cases where other systematic  
errors are small (ie no radiation damage, absorption etc etc) are very  
close to 1.0.


Best wishes,

Andrew




On 3 Mar 2011, at 20:34, Bryan Lepore wrote:


wondering if mosflm can automatically estimate the gain.

i.e. i gather it is still estimated the usual way.

-Bryan

Re: [ccp4bb] mosflm gain

[A Leslie]

Dear All,

spotted a mistake in my response, please see the correction below (in  
bold):


There are a host of caveats in this procedure. For example, if the  
images contains significant diffuse scatter around the Bragg spots,  
the BGRATIO may be above 1.0 ... this is probably the commonest  
effect, but does not mean the gain is wrong. If for any reason the  
mask definition (defining the boundary between background and spot)  
has not worked correctly so the spot extends into the background, this  
will also give a BGRATIO of GREATER THAN one (in this case, the  
BGRATIO will tend to be close to 1.0 for weak spots but greater than  
1.0 for strong ones). The boundary is controlled by the Profile  
tolerance parameters, which are sometimes set artificially high to  
help process images where the spots are not fully resolved.


Andrew

On 3 Mar 2011, at 20:34, Bryan Lepore wrote:


wondering if mosflm can automatically estimate the gain.

i.e. i gather it is still estimated the usual way.

-Bryan

[ccp4bb] X-ray facility Scientist at MRC LMB, Cambridge, UK

[A Leslie]

X-Ray Facility Scientist
MRC Laboratory of Molecular Biology
Cambridge
£26,022 – £31,758

We wish to recruit an Investigator Scientist to join the MRC  
Laboratory of Molecular Biology X-ray facility in Cambridge, UK. You  
will provide support for a range of projects involving X-ray  
crystallographic data collection both in-house and at synchrotrons.  
You would also be responsible for optimising the performance of the in- 
house X-ray facilities, liaising with maintenance engineers and  
helping to train new users. The position requires extensive travel to  
synchrotrons both in UK and abroad.


You should have a PhD in a relevant subject and experience in X-ray  
crystallographic data collection.


Your salary will be supported by a flexible pay and reward policy, 30  
days annual leave entitlement, an optional MRC final salary pension  
scheme and excellent on-site sports and social facilities.


Applications are handled by the RCUK Shared Services Centre; to apply  
please visit our job board at https://ext.ssc.rcuk.ac.uk and complete  
an online application form. Applicants who would like to receive this  
advert in an alternative format (e.g. large print, Braille, audio or  
hard copy), or who are unable to apply online should contact us by  
telephone on 01793 867003, Please quote reference number IRC14067.


Closing date: 16th March 2011



For informal enquiries please email: and...@mrc-lmb.cam.ac.uk





 
   

Re: [ccp4bb] How do I set up a Refmac5 dictionary to constrain octahedrally coordinated Ca++

[A Leslie]

Hi Pietro,

There  are monomer library entries for Ca in various states of  
coordination by water, entries, OC1, OC2,OC3 etc but unfortunately  
these are incomplete (no distances or angles with sd's), at least in  
our CCP4 installation. The entry for octahedral MG-O6, file MO6, is  
complete so you could use that as a model if you want to. The  
advantage of these entries is that they restrain angles as well as  
distances (eg O-MG-O, or O-CA-O in your case), ie it will keep it  
octahedral.



Andrew




On 10 Sep 2010, at 14:56, Pietro Roversi wrote:


Dear all,

How do I set up a Refmac dictionary to constrain octahedrally  
coordinated Ca++?


Refmac5 seems to detect the potential bond between the Ca++ and the  
ligands:


INFO: link is found (not be used) dist=   2.229 ideal_dist=
2.320
   ch:AA   res: 263  GLU  at:O   .-ch:Ag   res: 600   
CA   at:CA  .


but it does not enforce them, and I cannot figure out what the
CCP4 convention for a O-Ca++ bond is.

Thanks for any suggestions!

Pietro

Re: [ccp4bb] non-symmetric tetramer ?

[A Leslie]

Hi Fred,

 If your tetramer show negative cooperativity between the 4  
sites for ligand binding, then it is possible to get a tetramer with  
(say) only one subunit occupied by ligand, which can introduce  
considerable asymmetry if ligand binding gives rise to a  hinge type  
closure of two domains around the ligand site. An example of this is  
glyceraldehyde 3-phosphate dehydrogenase which has been solved with  
one, two (and possibly 3) NADs bound per tetramer. I'm afraid you will  
need to do a literature search to find the references, but AJ Wonacott  
will be one of the authors.


Cheers

Andrew


On 28 Jul 2010, at 19:31, Fred wrote:


Dear CCP4bb,
Could someone please, point me to some references about non- 
symmetric tetramers? If I have a tetramer composed by 4 identical  
subunits, it'll always have a P4 point group symmetry?

Thank in advance,
Tomb

Re: [ccp4bb] How to orient molecules in pymol according to the crystal orientation during data collection?

[A Leslie]

Dear Anja,

 I'm not sure why you want the orientation of the  
molecule in pymol, but working out the orientation of the crystal at  
phi=0 is straightforward in imosflm.


Read the image, index it and go to Strategy. In the strategy pane it  
gives the angles between the a,b,c axes of the crystal and the  
laboratory X,Y,Z coordinate frame. X is along the X-ray beam, Z along  
the rotation axis.


Andrew

On 7 Jul 2010, at 16:22, Anja Pomowski wrote:


Hi there,

we were taking UV/ vis spectra of a protein crystal that show
different features depending on the crystal orientation in the beam.
The question is now how to correlate the UV/ vis spectra with the  
solved
structure. We know that it has a special feature at e.g. image 1  
(0°). So

how can we get the orientation of the molecule in pymol so that it
corresponds to its orientation in the crystal at that exact image?

Thanks a lot,

Anja





Anja Pomowski

Universität Freiburg
Institut f. Organ. Chemie und Biochemie
AK Prof. Einsle
Albertstr. 21
79104 Freiburg

Tel. 0761 2036088
Fax. 0761 2036161

Re: [ccp4bb] How to see miller indeces onto images

[Andrew Leslie]

Dear Marco,

   I'm not sure exactly what you want (for example do you want the
indices of ALL reflections to be shown or just individual ones)
but iMosflm (CCP4 package) may be able to do what you want.

After indexing the image, the predicted reflections will be displayed (as
boxes). If you hold down the Alt key, moving the mouse over a reflection
will display its indices. Alternatively, if you wish to find a particular
reflection, use the Tools drop down menu and select Find HKL (this is
the only option at present) and enter the indices. A cross will then be
drawn at the position of that reflection. If you want to follow a
reflection across several images, simply zoom the image so that the
reflection of interest is in the centre of the zoom box (and not many
reflections are shown). If another image is selected, the same (zoomed)
part of the image will be shown, so it is easy to find the same
reflection.

Best wishes,

Andrew


 Dear all,

 Is there an image indexing program that assigns and shows the Miller
 indices onto the image itself, or maybe can read the indexing matrix to
 point these indeces onto the image for inspection? I tried to use LABELIT,
 but it showed the integrated Bragg spots as circles without the indeces.
 The aim is
 look at particular reflections into the original film and to observe
 possible
 intensity modulation. Anyone knows a tool that do it?

 Thanks.

 Marco Antonio Seiki Kadowaki
 Department of Biochemistry and Molecular Biology
 Universidade Federal do Paraná
 Curitiba-Pr - Brazil

[ccp4bb] LAST CHANCE TO REGISTER FOR DIFFRACTION METHODS GRC

[A Leslie]

The biannual Gordon Conference on Diffraction Methods in Structural
Biology will be held at Bates College in Lewiston, Maine from 18-23rd
July. The program covers all aspects of macromolecular structure  
solution

from crystallization to structure solution and refinement and includes
sessions on complementary techniques and the potential of free electron
lasers. Many of the leading methods developers will be present and the
format of the meeting, with free afternoons, provides ample  
opportunities

for informal discussions.


The registration deadline is *** THIS COMING SUNDAY, 27th June ***

= 

Limited funds are still available to support new student and  
postdoctoral

applications, contact and...@mrc-lmb.cam.ac.uk for details.
= 



Further details, including a full program and details on the application
procedure can be obtained from:

http://www.grc.org/programs.aspx?year=2010program=diffrac

We hope to see you there !

Andrew Leslie (Chair)  Ana Gonzalez (Vice Chair)


Outline Program

Diffraction Methods in Structural Biology, 18-23rd July 2010, Bates
College, Lewiston, Maine

Sunday pm: Macromolecular Structures, Pushing the boundaries
Discussion leader: Michael Rossmann

1. ABC Transporters: Doug Rees

2.  The Spliceosome : Kyoshi Nagai

Monday am:  Crystallisation and the diffraction experiment
Discussion leader: Bob Sweet

1. Nanolitre crystallisation:  Seth Harris

2. Twinning and disorder: Todd Yeates

3. Simulating the diffraction experiment: James Holton

4. Microcrystallography:  Gwyndaf Evans

Monday pm: Radiation damage and data collection strategies
Discussion leader: Vivian Stojanoff

1. Radiation damage, experimental: Martin Weik

2.  Microbeams: Yanhui Zou

3. Testing data collection strategies with the Pilatus: Marcus Mueller

Tues am: Synchrotron developments and automated data processing
Discussion leader: Thomas Schneider

1. Synchrotrons, latest developments: Sean Mc Sweeney

2. Synchrotrons, latest developments:  Janet Smith

3. Data processing with Xia2/CHEF: Graeme Winter

4. Data processing with AUTOPROC: Clemens Vonrhein

Tues pm:  Complementary techniques
Discussion leader: Ana Gonzales

1. Electron tomography: Sriram Subramaniam

2. SAXS: Hiro Tsuruta

3. Spectroscopy: Carrie Wilmot

Weds am: Structure solution and refinement
Discussion leader:  Paul Adams

1. SAD Phasing: Randy Read

2. Molecular replacement with BALBES: Garib Murshudov

3. PHENIX: Tom Terwilliger

4. TLS: Ethan Merritt

Weds pm:  Challenging problems/Membrane Proteins
Discussion leader: Michael Wiener

1. Using cubic lipidic phase: Martin Caffrey

2. Membrane Proteins: Stephen White

3. Heterogeneity, low solubility and low resolution: structural  
pursuit on

the ternary Myddosome complex in Toll-like receptor signaling: Hao Wu

Thurs am:  Selected Posters and Map improvement and Model building
Discussion leader: Tassos Perrakis

1. COOT: Paul Emsley

2. Modelling nucleic acids: Johan Hattne

Thursday pm: Future Methods, FELs, Diffraction imaging
Discussion leader:  Ed Lattman

1. Opportunities fof membrane protein analysis with FELs: Petra Fromme

2. Single particle imaging with pulsed hard Xray lasers: Anton Barty

3. Femtosecond nanocrystallography of membrane proteins using LCSL: John
Spence

[ccp4bb] Diffraction Methods GRC, Registration deadline is 27th June

[Andrew Leslie]

The biannual Gordon Conference on Diffraction Methods in Structural
Biology will be held at Bates College in Lewiston, Maine from 18-23rd
July. The program covers all aspects of macromolecular structure solution
from crystallization to structure solution and refinement and includes
sessions on complementary techniques and the potential of free electron
lasers. Many of the leading methods developers will be present and the
format of the meeting, with free afternoons, provides ample opportunities
for informal discussions.


The registration deadline is 27th June, so please apply soon !

=
Limited funds are available to support new student and postdoctoral
applications, contact and...@mrc-lmb.cam.ac.uk for details.
=

Further details, including a full program and details on the application
procedure can be obtained from:

http://www.grc.org/programs.aspx?year=2010program=diffrac

We hope to see you there !

Andrew Leslie (Chair)  Ana Gonzalez (Vice Chair)


Outline Program

Diffraction Methods in Structural Biology, 18-23rd July 2010, Bates
College, Lewiston, Maine

Sunday pm: Macromolecular Structures, Pushing the boundaries
Discussion leader: Michael Rossmann

1. ABC Transporters: Doug Rees

2.  The Spliceosome : Kyoshi Nagai

Monday am:  Crystallisation and the diffraction experiment
Discussion leader: TBA

1. Nanolitre crystallisation:  Seth Harris

2. Twinning and disorder: Todd Yeates

3. Simulating the diffraction experiment: James Holton

4. Microcrystallography:  Gwyndaf Evans

Monday pm: Radiation damage and data collection strategies
Discussion leader: Vivian Stojanoff

1. Radiation damage, experimental: TBA

2.  Microbeams: Yanhui Zou

3. Testing data collection strategies with the Pilatus: Marcus Mueller

Tues am: Synchrotron developments and automated data processing
Discussion leader: Thomas Schneider

1. Synchrotrons, latest developments: Sean Mc Sweeney

2. Synchrotrons, latest developments:  Janet Smith

3. Data processing with Xia2/CHEF: Graeme Winter

4. Data processing with AUTOPROC: Clemens Vonrhein

Tues pm:  Complementary techniques
Discussion leader: Ana Gonzales

1. Electron tomography: Sriram Subramaniam

2. SAXS: Hiro Tsuruta

3. Spectroscopy: Carrie Wilmot

Weds am: Structure solution and refinement
Discussion leader:  Paul Adams

1. SAD Phasing: Randy Read

2. Molecular replacement with BALBES: Garib Murshudov

3. PHENIX: Tom Terwilliger

4. TLS: Ethan Merritt

Weds pm:  Challenging problems/Membrane Proteins
Discussion leader: TBC

1. Using cubic lipidic phase: Martin Caffrey

2. Membrane Proteins: Stephen White

3. Heterogeneity, low solubility and low resolution: structural pursuit on
the ternary Myddosome complex in Toll-like receptor signaling: Hao Wu

Thurs am:  Selected Posters and Map improvement and Model building
Discussion leader: Tassos Perrakis

1. COOT: Paul Emsley

2. Modelling nucleic acids: Johan Hattne

Thursday pm: Future Methods, FELs, Diffraction imaging
Discussion leader:  Ed Lattman

1. Opportunities fof membrane protein analysis with FELs: Petra Fromme

2. Single particle imaging with pulsed hard Xray lasers: Anton Barty

3. Femtosecond nanocrystallography of membrane proteins using LCSL: John
Spence

Re: [ccp4bb] Scaling question

[A Leslie]

Dear Simon,

 mosflm does indeed estimate the intensity of  
overloaded reflections, and these are rejected by default in SCALA,  
but you can choose to include them using the appropriate keywords  
(ACCEPT OVERLOADS). The number of overloads in the MTZ file, and the  
number accepted for output, are reported by SCALA in the logfile.


Andrew


On 7 Jun 2010, at 15:09, Simon Kolstoe wrote:


Dear CCP4bb,

I was wondering if someone could tell me how mosflm and scala deal  
with overloaded reflections. From my understanding mosflm  
extrapolates the overloaded peaks but then scala throws them out  
completely - is this right?


If so am I right to not worry about contamination from  
extrapolated peaks when combining high and low resolution datasets  
from the same crystal?


Thanks

Simon

[ccp4bb] Gordon Conference on Diffraction Methods

[A Leslie]

Just a reminder that there is still time to register for the Gordon  
Conference on Diffraction Methods in Structural Biology, that will be  
held at Bates College in Lewiston, Maine from 18-23rd July.


The program (see below) covers all aspects of macromolecular  
crystallography, from crystallization to structure solution and  
refinement, and includes sessions on complementary techniques and the  
potential of free electron lasers.


Many of the leading methods developers will be present and the format  
of the meeting, with free afternoons, provides ample opportunities for  
informal discussions.


Further details, including a full program and details on the  
application procedure can be obtained from:


http://www.grc.org/programs.aspx?year=2010program=diffrac

We hope to see you there !

Andrew Leslie (Chair)  Ana Gonzalez (Vice Chair)


Outline Program:
Sunday pm: Macromolecular Structures, Pushing the boundaries

Discussion leader: Michael Rossmann

 1. ABC Transporters: Doug Rees

 2.  The Spliceosome : Kyoshi Nagai



Monday am:  Crystallisation and the diffraction experiment

Discussion leader: Zbyszek Dauter

 1. Nanolitre crystallisation:  Seth Harris

 2.  Twinning and disorder: Todd Yeates

 3. Simulating the diffraction experiment: James Holton

 4. Microcrystallography:  Gwyndaf Evans



Monday pm: Radiation damage and data collection strategies

Discussion leader: Vivian Stojanoff

 1. Radiation damage, experimental: Elspeth Garman

 2.  Microbeams: Yanhui Zou

 3. Testing data collection strategies with the Pilatus: Marcus Mueller



Tues am: Synchrotron developments and automated data processing

Discussion leader: Thomas Schneider

 1. Synchrotrons, latest developments: Sean Mc Sweeney

 2. Synchrotrons, latest developments:  Janet Smith

 3. Data processing with Xia2/CHEF: Graeme Winter

 4. Data processing with AUTOPROC: Clemens Vonrhein



Tues pm:  Complementary techniques

Discussion leader: Ana Gonzales

 1. Electron tomography: Sriram Subramaniam

 2. SAXS: Hiro Tsuruta

 3. Spectroscopy: Carrie Wilmot



Weds am: Structure solution and refinement

Discussion leader:  Paul Adams

 1. SAD Phasing: Randy Read

 2. Molecular replacement with BALBES: Garib Murshudov

 3. PHENIX: Tom Terwilliger

 4. TLS: Ethan Merritt



Weds pm:  Challenging problems/Membrane Proteins

Discussion leader: TBC

 1. Using cubic lipidic phase: Martin Caffrey

 2. Membrane Proteins: Stephen White

 3. The Bacterial Ribosome: Venki Ramakrishnan



Thurs am:  Selected Posters and Map improvement and Model building

Discussion leader: Tassos Perrakis

 1. COOT: Paul Emsley

 2. Modelling nucleic acids: Johan Hattne



Thursday pm: Future Methods, FELs, Diffraction imaging

Discussion leader:  Ed Lattman

 1.  Anton Barty

2.  Serial Crystallography: John Spence and Petra Fromme