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 



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 


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


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/