Re: [ccp4bb] Diffraction Methods 2024

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear All,

A reminder that this meeting is taking place in July - we have an interesting 
programme coming together in both the main research methods conference and the 
associated seminar, details are on the meeting page at:

https://events.gwdg.de/event/650/

Many thanks to all those who have already registered

We look forward to seeing you there - as before if you have any questions 
please get in touch via diffmet2...@physnet.uni-hamburg.de

Best wishes Graeme

On behalf of the organisers of both events, Graeme Winter, Kunio Hirata, Helena 
Taberman, Ali Ebrahim, Arwen Pearson and Ashwin Chari

From: diffmet2024-boun...@physnet.uni-hamburg.de 
 on behalf of Winter, Graeme 
(DLSLtd,RAL,LSCI) 
Sent: 05 February 2024 09:56
To: CCP4BB@JISCMAIL.AC.UK 
Cc: diffmet2...@physnet.uni-hamburg.de 
Subject: [Diffmet2024] Diffraction Methods 2024

Dear CCP4BB,

As some of you may remember we are keeping the spirit of the GRC in diffraction 
methods in structural biology alive. Accordingly I would like to announce, on 
behalf of the meeting organisers

Diffraction Methods 2024

Which will be held 22nd - 27th July 2024 at the Harnack House in Berlin, with 
the focus around the tension between experiments and measurements in structural 
biology, specifically around diffraction methods.

For more detail about the meeting and registration please visit

https://events.gwdg.de/event/650/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevents.gwdg.de%2Fevent%2F650%2F=05%7C02%7CGraeme.Winter%40diamond.ac.uk%7C7728b37e8aee4c836f4008dc2630cf65%7C9d27ba7401004d0d81ff1d728dae8df6%7C0%7C0%7C638427238284600557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=MEe7AsythcueTPI4nJHWKGtEotWUMqEKNzfFS0RxuZk%3D=0>

We are hoping to encourage as many early career researchers as possible - the 
last GRC had a fantastic mix of the new and the experienced which we would like 
to replicate. Therefore if you consider yourself to be early career person, 
please consider attending!

We look forward to seeing you there - if you have any questions please get in 
touch via diffmet2...@physnet.uni-hamburg.de

Best wishes Graeme

On behalf of the organisers of both events, Graeme Winter, Kunio Hirata, Helena 
Taberman, Ali Ebrahim, Arwen Pearson and Ashwin Chari

[https://events.gwdg.de/event/650/attachments/533/901/Diff_Met2024_Poster.001.jpeg]




--

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


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.



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] i2 won't accept 90 degree angles in moniclinic

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Huw

(first: thank to Phil for picking this up; it caused much confusion)

While I get where you are coming from, it is still from a mathematical 
standpoint correct to consider e.g. a tetragonal crystal as monoclinic - P21 is 
a subgroup of P43212 (say) so strictly it is possible and correct - if 
experimentally unlikely - to have the situation we are discussing here occur. 

Also, under merging data to investigate twinning is a current bb topic.

Telling users to “fiddle the parameters” so that the strict test is satisfied 
feels like a non-ideal answer: a warning when importing such data could be 
legitimate e.g. “hmm I note a = b and al=be=ga=90 _exactly_ this is unusual, I 
hope you know what you are doing” rather than a flat out error.

Literally I got involved as I had a dials user ask me how to do this parameter 
fiddling in a more niche case and I thought that was a suboptimal solution to 
an artificial problem :-) 

On a personal note, I think it is important that the tools we develop still 
allow people to explore problems rather than railroading them down one true 
route which is the only allowed way to look at a problem: we learn a lot by 
exploring odd corners as here. 

Best wishes Graeme

> On 23 Feb 2024, at 09:49, Huw Jenkins  wrote:
> 
> [You don't often get email from h.t.jenk...@me.com. Learn why this is 
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Graeme,
> 
>> On 21 Feb 2024, at 16:52, Winter, Graeme (DLSLtd,RAL,LSCI) 
>> <6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote:
>> 
>> Processing a data set in lower than necessary symmetry e.g. tetragonal as 
>> monoclinic you _cannot_ import the merged MTZ file into i2 because it is 
>> impossible to have 90 degree angles for P21
> 
> I had a look at the code in CCP4i2 that generates the errors in the 
> screenshots you posted. The first one is only generated if two cell 
> parameters are *exactly* equal and the second is generated when beta is 
> between 89. and 90.0001 degrees.
> 
> I think these tests should only fail if the data were processed assuming 
> higher symmetry so that unit cell parameters were restrained and then the 
> space group changed to a lower symmetry one. Isn't the correct approach when 
> the true symmetry is lower than originally assumed to repeat the data 
> processing without applying constraints imposed by the higher symmetry - 
> because, for example, cell parameters refined assuming cell length/angle 
> constraints may not predict the reflection positions as well as if these 
> restraints were not applied, reflections assumed to be symmetry equivalent 
> when they weren't may lead to suboptimal scaling etc etc?
> 
> 
> Huw


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




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] i2 won't accept 90 degree angles in moniclinic

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Tried reporting to i2 dev list but it got bounced - feels like something others 
may hit so don’t feel _too_ bad sending to the bb with a tiny attachment


[cid:CA3CE9EB-841D-41A3-A41E-F79714492B21]

Hi Folks

Helping someone out with some rather specialist data processing challenges and 
she hit a problem: I can reproduce this with very boring thaumatin data so I 
think this is a bug

(it obliquely relates some to a current CCP4bb thread about MR, in passing)

Processing a data set in lower than necessary symmetry e.g. tetragonal as 
monoclinic you _cannot_ import the merged MTZ file into i2 because it is 
impossible to have 90 degree angles for P21

Well, it is possible, and also, it is still correct to under merge the data so 
this is a bug? Is this a reasonable viewpoint to hold?

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




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] Truncate / ctruncate / moments of E etc.

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Thanks Ian, that is much more what I was looking for!

I knew I had seen something like this a long time ago

All the best Graeme

On 14 Feb 2024, at 15:36, Ian Tickle 
mailto:ianj...@gmail.com>> wrote:

You don't often get email from ianj...@gmail.com<mailto:ianj...@gmail.com>. 
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

This has graphs: https://www.ccp4.ac.uk/html/pxmaths/bmg10.html .

-- Ian


On Wed, Feb 14, 2024 at 3:25 PM Winter, Graeme (DLSLtd,RAL,LSCI) 
<6a19cead4548-dmarc-requ...@jiscmail.ac.uk<mailto:6a19cead4548-dmarc-requ...@jiscmail.ac.uk>>
 wrote:
Absolutely! However

"(ie. not mathematics-first)”

I was thinking of something with more pictures and graphs in ;-)

I had already sent that newsletter but felt it may be a bit heavy going as a 
first introduction

All the best Graeme

On 14 Feb 2024, at 15:17, David Waterman 
mailto:dgwater...@gmail.com>> wrote:

Norman Stein's article at the back of this newsletter is the one I like!
https://legacy.ccp4.ac.uk/newsletters/newsletter47/newsletter47.pdf

-- David


On Wed, 14 Feb 2024 at 15:14, Winter, Graeme (DLSLtd,RAL,LSCI) 
<6a19cead4548-dmarc-requ...@jiscmail.ac.uk<mailto:6a19cead4548-dmarc-requ...@jiscmail.ac.uk>>
 wrote:
Good afternoon all,

Chatting to someone and wanted to provide some pointers on how to interpret the 
moments of E from truncate or ctruncate, and realised that I don't have any 
good references​ for this to hand i.e. what I am looking for and why, and my 
google search didn't come up with much that was useful

Those of us who have a few orbits under out belts picked up a lot of this from 
osmosis but if you are trying to explain to someone new it's a bit more tricky

What have I missed? Where would you point people today to understand e.g. 
Wilson stats and suchlike, from a user perspective (ie. not mathematics-first)

Thanks in advance for any pointers

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




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




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] Truncate / ctruncate / moments of E etc.

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Absolutely! However

"(ie. not mathematics-first)”

I was thinking of something with more pictures and graphs in ;-)

I had already sent that newsletter but felt it may be a bit heavy going as a 
first introduction

All the best Graeme

On 14 Feb 2024, at 15:17, David Waterman 
mailto:dgwater...@gmail.com>> wrote:

Norman Stein's article at the back of this newsletter is the one I like!
https://legacy.ccp4.ac.uk/newsletters/newsletter47/newsletter47.pdf

-- David


On Wed, 14 Feb 2024 at 15:14, Winter, Graeme (DLSLtd,RAL,LSCI) 
<6a19cead4548-dmarc-requ...@jiscmail.ac.uk<mailto:6a19cead4548-dmarc-requ...@jiscmail.ac.uk>>
 wrote:
Good afternoon all,

Chatting to someone and wanted to provide some pointers on how to interpret the 
moments of E from truncate or ctruncate, and realised that I don't have any 
good references​ for this to hand i.e. what I am looking for and why, and my 
google search didn't come up with much that was useful

Those of us who have a few orbits under out belts picked up a lot of this from 
osmosis but if you are trying to explain to someone new it's a bit more tricky

What have I missed? Where would you point people today to understand e.g. 
Wilson stats and suchlike, from a user perspective (ie. not mathematics-first)

Thanks in advance for any pointers

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




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/

[ccp4bb] Truncate / ctruncate / moments of E etc.

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Good afternoon all,

Chatting to someone and wanted to provide some pointers on how to interpret the 
moments of E from truncate or ctruncate, and realised that I don't have any 
good references​ for this to hand i.e. what I am looking for and why, and my 
google search didn't come up with much that was useful

Those of us who have a few orbits under out belts picked up a lot of this from 
osmosis but if you are trying to explain to someone new it's a bit more tricky

What have I missed? Where would you point people today to understand e.g. 
Wilson stats and suchlike, from a user perspective (ie. not mathematics-first)

Thanks in advance for any pointers

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




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] Diffraction Methods 2024

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear CCP4BB,

As some of you may remember we are keeping the spirit of the GRC in diffraction 
methods in structural biology alive. Accordingly I would like to announce, on 
behalf of the meeting organisers

Diffraction Methods 2024

Which will be held 22nd - 27th July 2024 at the Harnack House in Berlin, with 
the focus around the tension between experiments and measurements in structural 
biology, specifically around diffraction methods.

For more detail about the meeting and registration please visit

https://events.gwdg.de/event/650/

We are hoping to encourage as many early career researchers as possible - the 
last GRC had a fantastic mix of the new and the experienced which we would like 
to replicate. Therefore if you consider yourself to be early career person, 
please consider attending!

We look forward to seeing you there - if you have any questions please get in 
touch via diffmet2...@physnet.uni-hamburg.de

Best wishes Graeme

On behalf of the organisers of both events, Graeme Winter, Kunio Hirata, Helena 
Taberman, Ali Ebrahim, Arwen Pearson and Ashwin Chari

[https://events.gwdg.de/event/650/attachments/533/901/Diff_Met2024_Poster.001.jpeg]


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




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] radiation damage and image discard

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Along similar lines, if you happen to be working in the DIALS ecosystem there 
is the dials.damage_analysis program, which takes the scaled data (scaled.expt, 
scaled.refl) and computes a number of statistics including Rd as discussed 
below, and the cumulative-pairwise R factor Rcp, which measures how well new 
batches of reflections agree with those measured before - back in the day this 
was also implemented in the CCP4 program “chef” which may even still be 
distributed, which takes scaled but *unmerged* data in MTZ format, and so can 
work from data from XDS and other software as well

The details of this are described in §5.2 of 
https://journals.iucr.org/d/issues/2019/03/00/ba5301/

(shameless plug, sorry, but it is the easiest public reference for it)

The short version is along the lines of -
- the measure of agreement of pairwise R factors is, in the absence of damage, 
directly related to the I/sigma of the data
- if the new measurements agree with those measured thus far, the trends are 
neutral / flat
- if the new measurements are different from those who came before, the trends 
are monotonically upwards

The dials.damage_analysis and chef tools also plot a completeness vs. dose 
(usually frame number as a proxy) which can give an indication of when you 
could consider cutting the data without harming the completeness of measurements

The reason why Rcp was developed from Rd was that the latter indicates the 
presence of damage, but the former also gives some hints as to the point where 
this damage becomes evident

I hope this is helpful, best wishes Graeme



> On 31 Oct 2023, at 09:26, Harry Powell 
> <193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote:
>
> Hi
>
> I’ve never actually used it in anger (one should never be angry when 
> processing data…), but doesn’t AutoProc, developed by the good folks at 
> Global Phasing do a lot of these analyses? Clemens, Claus etc may have 
> something pertinent to say.
>
> Harry
>
>> On 30 Oct 2023, at 13:23, Jorge Iulek  wrote:
>>
>> Dear all,
>>
>>  I have found many fundamental studies on image processing and 
>> refinement indexes concerning the decision on cutting resolution for a 
>> dataset, always meant to get better models, the final objective. Paired 
>> refinement has been a procedure mostly indicated.
>>  I have been searching studies alike concerning, in these days of 
>> thousands of collected images and strong x ray beams, the cutting (or 
>> truncation) of the (sequentially due to rotation method) recorded images in 
>> a dataset due to radiation damage. Once again, I understand the idea is to 
>> always produce better models.
>>  On one hand, the more images one uses, the higher the multiplicity, 
>> what (higher multiplicity) leads to better averaged intensity (provided 
>> scaling makes a good job), on the other hand, the more images one uses, 
>> lower intensity (due to the radiation damage) equivalent reflections come 
>> into play for scaling, etc. How to balance this? I have seen a case in which 
>> truncating images with some radiation damage led to worse CC(1/2) and 
>>  (at the same high resolution shell, multiplicities around 12.3 and 
>> then 5.7), but this might not be the general finding. In a word, are there 
>> indicators of the point where to truncate more precisely the images such 
>> that the dataset will lead to a better model? I understand tracing a sharp 
>> borderline might not be trivial, but even a blurred borderline might help, 
>> specially in the moment of image processing.
>>  I find that in 
>> https://ccp4i2.gitlab.io/rstdocs/tasks/aimless_pipe/scaling_and_merging.html#estimation-of-resolution
>>  there is a suggestion to try refinement with both truncating and not 
>> truncating.
>>  Sure other factors come into play here, like diffraction anisotropy, 
>> crystal internal symmetry, etc., but to start one might consider just the 
>> radiation damage due to exposure to x rays. Yes, further on, it would be 
>> nice the talk evolves to those cases when we see peaks and valleys along the 
>> rotation due to crystal anisotropy, whose average height goes on diminishing.
>>  Comments and indications to papers and material to study are welcome. 
>> Thanks.
>>  Yours,
>>
>> Jorge
>>
>> 
>>
>> 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 http://www.jiscmail.ac.uk/CCP4BB, a 
>> mailing list hosted by http://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 

Re: [ccp4bb] Database for submitting unprocessed diffraction data

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear Mirek

Scraping metadata from the image headers is a very nice idea

I wonder, how sustainable is your system? For example would I be thanked or 
cursed for uploading substantial interesting data sets?

One of the advantages of Zenodo, as much publicised and also highlighted by 
Loes, is the sustainability element - CERN are well equipped to curate vast 
amounts of data, and the Zenodo organisation is explicitly funded to support 
this

Best wishes Graeme

> On 19 Oct 2023, at 13:10, Mirek Gilski  wrote:
>
> Dear Jerome,
>
> You can consider a Macromolecular Xtallography Raw Data Repository (MX-RDR), 
> which is a dedicated archive of raw diffraction data collected for 
> macromolecular crystals. It includes tools for creating sets of 
> crystallographic metadata by combining information extracted directly from 
> diffraction image headers and obtained from the PDB deposit and/or user input.
> The MX-RDR repository is located at https://mxrdr.icm.edu.pl/
>
> All the best,
> Mirek Gilski
>
>
> ---
> -
> Prof. UAM dr hab. Mirosław Gilski
> Crystallography Department
> Faculty of Chemistry AMU
> Poznan, Poland
> mi...@amu.edu.pl
> -
>
> On 18.10.2023 18:23, JEROME JOHNSON wrote:
>> Hello all,
>>
>> As the subject says, I am looking for an open online database to store 
>> unprocessed diffraction data.  Does such a database exist? Essentially we 
>> would like our diffracted data to be freely available online while also 
>> outsourcing some of our data management.
>>
>> Any advice would be wonderful!
>>
>> Best,
>> Jerome
>>
>> 
>>
>> 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 http://www.jiscmail.ac.uk/CCP4BB, a 
> mailing list hosted by http://www.jiscmail.ac.uk/, terms & conditions are 
> available at https://www.jiscmail.ac.uk/policyandsecurity/


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




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] Outlawed PDB files, what should a muggle do

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Thanks David (and others who replied the same off list)

Yes, this is exactly what I wanted thank you

Agree that dimple should probably accept mmCIF, but for the moment I have the 
capacity to compute maps so jobsagoodun

All the best Graeme

From: David Waterman 
Sent: 20 September 2023 16:35
To: Winter, Graeme (DLSLtd,RAL,LSCI) 
Cc: CCP4BB@jiscmail.ac.uk 
Subject: Re: [ccp4bb] Outlawed PDB files, what should a muggle do

gemmi convert --shorten 7qgf.cif foo.pdb

?
-- David


On Wed, 20 Sept 2023 at 15:57, Winter, Graeme (DLSLtd,RAL,LSCI) 
<6a19cead4548-dmarc-requ...@jiscmail.ac.uk<mailto:6a19cead4548-dmarc-requ...@jiscmail.ac.uk>>
 wrote:
Looks like PDB files have been outlawed because mmCIF

But dimple needs PDB files

cif2pdb says nope

Grey-Area work :( $ cif2pdb --help

 * ERROR *
  No cif file read on input

Grey-Area work :( $ cif2pdb ~/Downloads/7qgf.cif

 * ERROR *
  No cif file read on input


Grey-Area work :( $ cif2pdb CIFIN ~/Downloads/7qgf.cif

 * ERROR *
  No cif file read on input



For someone who only used PDB files to get F^2 to validate processing, how best 
to get one *from the command line* ?

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



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<http://www.jiscmail.ac.uk/CCP4BB>, a mailing list 
hosted by www.jiscmail.ac.uk<http://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/

[ccp4bb] Outlawed PDB files, what should a muggle do

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Looks like PDB files have been outlawed because mmCIF

But dimple needs PDB files

cif2pdb says nope

Grey-Area work :( $ cif2pdb --help

 * ERROR *
  No cif file read on input 

Grey-Area work :( $ cif2pdb ~/Downloads/7qgf.cif 

 * ERROR *
  No cif file read on input 

 
Grey-Area work :( $ cif2pdb CIFIN ~/Downloads/7qgf.cif 

 * ERROR *
  No cif file read on input 



For someone who only used PDB files to get F^2 to validate processing, how best 
to get one *from the command line* ?

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



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] Determining Second Lattice

[Winter, Graeme (DLSLtd,RAL,LSCI)]

If you are already using dials anyway, adding

max_lattices=3

Say to the dials.index command line will probably do what you want

You can also look at them all in the reciprocal lattice viewer. 

All the best Graeme 

> On 31 Aug 2023, at 09:20, Harry Powell 
> <193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote:
> 
> Hi Matt
> 
> Call me old-fashioned but I’d use Mosflm for this. The multiple lattice 
> autoindexing is easy to run and easy to interpret.
> 
> Harry
> 
>> On 30 Aug 2023, at 16:20, Matt McLeod  wrote:
>> 
>> Hi all,
>> 
>> I have a lot of large datasets that I want to screen to determine if there 
>> are one or two lattices in the diffraction.  I was wondering if there was a 
>> simple and quick way to do so.
>> 
>> Currently, I am processing with DIALS and getting to the indexing where the 
>> percent indexed indicates if there is potentially a second lattice - and 
>> then visually inspected when there is a significant number of rejection.
>> 
>> I have autoprocess log files ie aimless.log, autoindex.log, fast_dp.log that 
>> were generated at the beamline but I cannot see a similar metric suggesting 
>> second lattices. 
>> 
>> Any insight would be appreciated!
>> Matt
>> 
>> 
>> 
>> 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/

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




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] Patenting ligand binding?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Discussion topics:

 - does this have any hope of being enforced since - as you point out - it is a 
pretty obvious next step from X-rays
 - does anyone else who is _already doing this_ care
 - should we (individuals, not community) be patenting the obvious / ideas / 
“inventions” just in case?

(well aware that the authors of said patent will wake up to this in a few 
hours) 

Personally, I am not comfortable with this, but maybe I am a dinosaur?

Graeme

> On 28 Jul 2023, at 09:13, Tim Gruene  wrote:
> 
> Hi Graeme,
> 
> do you want to discuss whether obvious steps can be patented?
> 
> Cheers,
> Tim
> 
> 
> On Fri, 28 Jul 2023 07:45:38 + "Winter, Graeme (DLSLtd,RAL,LSCI)"
> <6a19cead4548-dmarc-requ...@jiscmail.ac.uk> wrote:
> 
>> Interesting
>> 
>> https://www.freepatentsonline.com/20230228695.pdf
>> 
>> Patent for use of electron diffraction to assess ligand binding
>> 
>> Stumbled across this because the patent application cites my work -
>> felt that this would be of interest to the community
>> 
>> … discuss?
>> 
>> Graeme
>> 
>> 
> 
> 
> 
> -- 
> --
> Tim Gruene
> Head of the Centre for X-ray Structure Analysis
> Faculty of Chemistry
> University of Vienna
> 
> Phone: +43-1-4277-70202
> 
> GPG Key ID = A46BEE1A
> 
> 
> 
> 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/


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




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] Patenting ligand binding?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Interesting

https://www.freepatentsonline.com/20230228695.pdf

Patent for use of electron diffraction to assess ligand binding

Stumbled across this because the patent application cites my work - felt that 
this would be of interest to the community

… discuss?

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




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] Is it possible to process master.h5 file using XDS Mac version (Intel)?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear Zhen

It certainly is. You need a plug-in called neggia or durin to do this. You’ll 
find details on the XDS wiki which you can google for. 

Best wishes Graeme

> On 3 Jun 2023, at 15:35, Zhen Gong  wrote:
> 
> I would like to process master.h5 file with XDS. This is the error message 
> after I typed in “xds_par XDS.INP”
> 
> * XDS * (VERSION Jan 10, 2022  BUILT=20220820)   2-Jun-2023
> Author: Wolfgang Kabsch
> Copy licensed until 31-Aug-2023 to
>  academic users for non-commercial applications
> No redistribution.
> 
> sh: H5ToXds: command not found
> 
> !!! ERROR !!! Cannot access file: XDS.tmp
> 
> However, as I read, H5ToXds is only available in Linux. Is it possible to 
> process master.h5 file using XDS Mac version (Intel)? Thank you very much for 
> your time and help in advance!
> 
> Best regards,
> Zhen
> 
> 
> 
> 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/

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




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] Issues with viewing images with dials

[Winter, Graeme (DLSLtd,RAL,LSCI)]

HI Zoe

If, from a terminal with CCP4 configured, you type

dials.image_viewer (path-to-hdf5-master-file)

Where (path-to-hdf5-master-file) is your file location, does it work?

All the i2 message says is “something went wrong” which is not super helpful

As a general rule, I also usually recommend pulling a DIALS release from


Installation — DIALS documentation
dials.github.io
[favicon.ico]


since sometimes the CCP4 version is lagging some

All the best Graeme

On 26 May 2023, at 10:11, Zoe Markham-Lee 
 wrote:

Hi everyone,

I am currently trying to view images with dials through CCP4i2 (on mac)
I have so far tried using the DUI but when importing files, nothing seems to 
happen… there are no error codes appearing as such but no images/experimental 
data is imported. I have tried this on both .cbf and .h5 file types but with no 
success on either.
I also then tried downloading a json file type to use the image viewer option 
found in ccp4i2 and received this error code

-ERROR- CTaskDials_image:9 Error in wrapper dials_image 1.0:: Failed starting 
external process - this can be due to a number of things, butusually is due to 
the command used by subprocess/QProcess not working for some reason. Missing 
inputfiles, bad commands, non-functional programs etc. Check log files and 
stdout.
Process: dials.image_viewer

 -ERROR- CTaskDials_image:47 Error in wrapper dials_image 
1.0:: Error in checking external process after completion
exit status and  code: 1 1

If anyone could advise me on what might be causing these issues I would be very 
grateful (as a side note I can view these .cbf images imosflm so I’m assuming 
the files are okay and hence the issue is something dials related?)

BW,
Zoe

--
Zoe Markham-Lee
PhD Student
Biodiscovery Institute (Phase1/2)
School of Pharmacy,
University of Nottingham,
University Park,
Nottingham.
NG72RD
--


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


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




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] Save the date! “Not the GRC” on Diffraction Methods in Structural Biology 2024

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Good morning all,

“Not the Gordon Research Conference” on Diffraction Methods in Structural 
Biology 2024 - Experiments and Measurements

Organisers:

Graeme Winter, Kunio Hirata (NTGRC-chairs)

Helena Taberman, Ali Ebrahim (NTGRS-chairs)

Local organisers - Arwen Pearson, Ashwin Chari

As you will have seen from a message from James Holton last year, the GRC have 
decided that the 2024 meeting on Diffraction Methods will not be further 
supported.

We are not deterred!

A number of the GRC ex-chairs and those nominated for chairing the next meeting 
feel that this opportunity for the diffraction methods community to come 
together is important enough that it should continue to happen, even without 
GRC support. We are therefore delighted to launch the “Not-the-GRC Diffraction 
methods in Structural Biology”. The topic of the meeting will be “Experiments 
and Measurements” and we have a great lineup of speakers in mind.

Where:

https://www.harnackhaus-berlin.mpg.de/en

When:

21st - 27th July 2024

i.e. about when the next diffraction methods meeting would have been. Starting 
with the model of the GRC, since we collectively believe it is a fantastic 
meeting, we plan to make a few improvements (better accommodation and 
acoustics, fewer minimum attendees to keep the feel of a small meeting) and we 
will keep the equivalent of the GRS before the main meeting, as well as the 
free afternoons for collaborative discussion, and the strong emphasis on being 
able to talk to everyone. We will also keep the focus on new ideas and so 
follow the protocol of not recording presentations and encouraging the 
presentation of unpublished data and ideas. 

With that in mind, this will be a small meeting (100-120 maximum) so there will 
be an application process and we will open registration in January 2024. We 
also want as many early career people as possible - the last GRC was refreshing 
and fun with a lot of new faces, and this is something we want to build on.

So, please hold the date in your calendar and we look forward to sharing the 
scientific programme with you in the coming months and seeing many of you in 
Berlin next summer. 

All the best Graeme, Kunio, Helena, Ali, Arwen and Ashwin


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




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] Future Diffraction Methods

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi All

One of the joys of this meeting to me is that it is *not* about the science 
results and instead explicitly about how you get to those results. I worry that 
any meeting focussed on complimentary methods would inevitably coalesce around 
the common themes - science results - and become yet another structural biology 
conference.

I appreciate the needs for structural biology conferences, but I would feel 
that they are already well met. The diffraction methods conference is unique in 
allowing methods people to get together - if we expand this to all biophysical 
/ biochemical methods then we completely lose that. Even if we did succeed in 
pulling in methods people from all techniques, the meeting would then become 
too big.

I am well aware that the majority of people in the community are interested in 
the results not the methods, and are hence interested in applying as many 
techniques as necessary to get the insights. I’d just like to make sure that 
there is a little corner left where the people who develop those techniques - 
which are usually pretty specialist - can get together. I am certain that folks 
in non-diffraction methods development feel the same.

All the best Graeme



On 30 Jan 2023, at 01:59, Bostjan Kobe 
mailto:b.k...@uq.edu.au>> wrote:

Hi guys

I would be a bit more optimistic about this idea… If people attend the meeting 
with the objective of building some bridges they will try.  I have been to 
meetings on a biological topic where I may have been the only structural 
biologist but it was clear why I was there and I did not feel isolated, despite 
not being able to participate in every technical discussion on methods I am not 
familiar with.

Bostjan

--
Bostjan Kobe FAA
Australian Laureate Fellow
Professor of Structural Biology
School of Chemistry and Molecular Biosciences
and Institute for Molecular Bioscience (Division of Chemistry and Structural 
Biology) and Australian Infectious Diseases Research Centre
Cooper Road
University of Queensland
Brisbane, Queensland 4072
Australia
Phone: +61 7 3365 2132
Fax: +61 7 3365 4699
E-mail: 
b.k...@uq.edu.au
URL: http://www.scmb.uq.edu.au/staff/bostjan-kobe
Office: Building 76 Room 329
Notice: If you receive this e-mail by mistake, please notify me, and do not 
make any use of its contents. I do not waive any privilege, confidentiality or 
copyright associated with it. Unless stated otherwise, this e-mail represents 
only the views of the Sender and not the views of The University of Queensland.



From: CCP4 bulletin board mailto:CCP4BB@JISCMAIL.AC.UK>> 
on behalf of Nukri Sanishvili mailto:sannu...@gmail.com>>
Reply to: Nukri Sanishvili mailto:sannu...@gmail.com>>
Date: Monday, 30 January 2023 at 11:40 am
To: "CCP4BB@JISCMAIL.AC.UK" 
mailto:CCP4BB@JISCMAIL.AC.UK>>
Subject: Re: [ccp4bb] Future Diffraction Methods

Hi Pavel,
Your description of the current status is exactly correct. And that's exactly 
what I am proposing to change or, more accurately, try to change. By seeking 
out and  bringing together people who do complementary and collaborative work, 
so they can set an example for others.
This, of course, isn't meant in place of more narrowly defined topical meetings 
and conferences but to be in addition to those.
James asked the community if we had new ideas and this is a new-ish approach I 
was suggesting.
Don't get me wrong - I myself will happily continue my efforts in more narrowly 
defined meetings.
Best wishes,
Nukri

On Sun, Jan 29, 2023 at 6:44 PM Pavel Afonine 
mailto:pafon...@gmail.com>> wrote:
Nukri,

IMO, the idea of cross-discipline meetings is great conceptually, at least for 
reasons you pointed out, but utopical in practice. When we attend our 
field-specific meetings we meet colleagues we know, we talk to collaborators 
from the past or find new ones, we have things in common that we can talk about 
to forge something new, we meet authors of papers we were excited to read, and 
so on, and so on.
I once attended a meeting of some chemistry society, well, which is not too far 
from what we are doing, really, as interpreting atomic models is essentially 
putting your chemistry knowledge into production. And, at that meeting I felt 
like I'm alone in a dark forest.
Now, I imagine, if you bring two (or more) groups of people to your meeting 
from two different domains, well, I guess you will end up having two bubbles of 
people clustered by their field of interest.

Same disclaimer goes here as yours -- no offence to any one, just thinking out 
loud...

All the best!
Pavel

On Sun, Jan 29, 2023 at 6:09 AM Nukri Sanishvili 
mailto:sannu...@gmail.com>> wrote:
Hi James,
This meeting has indeed been one of the best ones by its format, content, and 
atmosphere. Many thanks to all the organizers and attendees of the past. 
Nevertheless, it is not surprising that it was cancelled, given the trends in 
structural biology research. Straightforward evolutionary pressure to adapt or 

Re: [ccp4bb] Future Diffraction Methods

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear All,

This was not really discussed widely at the study weekend however I think we 
have a core group of people who are sufficiently committed to the “GRC on 
diffraction methods” cause that we will keep it alive - as chair elect I also 
hold a very strong belief that we should keep this going.

Currently we are exploring the opportunities for the “not the GRC on 
diffraction methods 2024” with an intent on keeping the spirit of the meeting 
alive, ideally with the meeting at about the same time it would have happened 
if the GRC had not been cancelled.

Best wishes Graeme


On 5 Jan 2023, at 14:04, Dekker, Carien 
mailto:carien.dek...@novartis.com>> wrote:

Happy New Year all,

Since I am not at the CCP4 weekend (which is happening right now), I would be 
curious to hear if this is/was discussed and what people think.

Carien

-Original Message-
From: CCP4 bulletin board mailto:CCP4BB@JISCMAIL.AC.UK>> 
On Behalf Of Frank von Delft
Sent: Monday, December 19, 2022 10:21 AM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Future Diffraction Methods

This Message is from an External Sender. Do not click links or open attachments 
unless you trust the sender.

Shoot... that sucks.

Yes, we do need something!

"Structural Biology Methods"?


More interesting question:  does it need the GRC to host?  What about 
reimagining the CCP4 study weekend - the question keeps coming up there anyway.

That's one for CCP4 WG1 to discuss - they're meeting straight after New Year, 
so maybe James, you and Ivo should hop on a zoom and kick the idea around.

Frank



On 16/12/2022 22:10, James Holton wrote:
I want to thank everyone who attended the 2022 Gordon Research
Conference and Gordon Research Seminar on Diffraction Methods in
Structural Biology, as well as all those who contributed to these
great gatherings in the past.  It was an outstanding meeting if I do
say so myself. Not just because it had been so long without in-person
interaction, not just because we had zero covid cases (which I see as
no small feat of Mind over Virus), but because of this amazing
community. It is rare in this world to have such a strong spirit of
collaboration, camaraderie and openness in undertakings as high-impact
as this. Surmounting the barriers to atomic-detail imaging of
biological systems has never been more exciting and more relevant.  I
am proud to be a part of it, and honored to have served as Chair.

It is therefore with heavy heart that I report to this community that
I was the last Chair of the Diffraction Methods GRC.

The GRC Conference Evaluation Committee
(https://urldefense.com/v3/__https://www.grc.org/about/conference-eval
uation-committee/__;!!N3hqHg43uw!seKRCwqf-9U5a5vpm19quTE94sOBoM1HzktB2
NDBxOp6TFV8LC_s19p5TJcgvxfLfp8BheaUlg1wOfursEBNL8h62_DMr_f2M1U$ )
voted this year to discontinue the Diffraction Methods GRC and GRS.
This ends a 46-year tradition that I feel played a vital, and vibrant
role in the work of the people who answer questions on this BB. The
reason given was insufficient attendance.  All other metrics, such as
evaluation surveys and demographics were very strong. I have tried to
appeal, but I'm told the vote was unanimous and final. I understand
that like so many conference organizing bodies the GRC is having to make tough 
financial decisions. I must say I disagree with this one, but it was not my 
decision to make.

Many of the past and elected Chairs have been gathering and discussing
how to replace the Diffraction Methods GRC/GRS going forward. Many
great ideas, advice and perspectives have been provided, but that is a
select group. I feel it is now time to open up this discussion to the
broader community of structural methods developers and practitioners.
There are some important questions to ask:

* How do we define this community?
   Yes, many of us do cryoEM too, but is that one methods
meeting? or two?
* Does this community need a new diffraction methods meeting?
   As in one meeting or zero?
* Should we merge with an existing meeting?
   It would make logistics easier, but a typical GRC has 22 hours
of in-depth presentations over 5 days.  The GRS is 7 hours over 2
days. As Chair, I found that was not nearly enough.
* Where do you think structural methods are going?
   I think I know, but I may be biased.
* Should the name change?
   From 1976 to 2000, it was "Diffraction Methods in Molecular
Biology". The word "diffraction", BTW, comes from the Latin for
"shattering of rays", and originally used to describe the iridescence
of bird feathers. That's spectroscopy!
How about:
"Structural Methods for the Departing of Rays"

I'm sure there are many more questions, and better suggestions.  I
look forward to enlightening discussions!  GRCs have always been about
discussion, and I hope to keep that tradition alive in this community.

-James Holton
MAD Scientist

##
##

To 

[ccp4bb] Photographic museum of X-ray diffraction detectors

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Season’s greetings everyone

It is of course the season to be preparing CCP4 study weekend presentations…. 
and I was looking for some photographs of vintage beamline hardware and in 
particular detectors that I used in the dim and distant past. 

Does anyone have a photograph of SRS 7.2 with the MAR345? Or the venerable ADSC 
Q4 on 14.2? 

I never took diffraction data on photographic film but I think I only just 
missed out, so any photographs of actual film diffraction data would also be 
awesome. 

For the well-being of people’s inboxes please get in touch off list. I will of 
course duly acknowledge any contributions and can put them somewhere modern 
like a git repo so they are available for others in the future. This will only 
be a brief part of the presentation but would like to make it complete. 

Many thanks in advance, 

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




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] Error while running BLEND

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Pedro

Problem here is that ccp4.python is Python 3 and BLEND is still written for 
Python 2.7

This was one of the modernisation things which changed from 2 -> 3

An older version of ccp4 would probably still work - version 7.something

Looks like BLEND needs to be updated… 

Best wishes Graeme

> On 11 Oct 2022, at 15:30, Pedro Matias  wrote:
> 
> Dear All,
> 
> I am trying to run BLEND on a series of XDS files in MTZ format. However, I 
> get the following error:
> 
>> Traceback (most recent call last):
>>   File "/pxsoft/ccp4/ccp4-8.0/share/blend/python/create_file_for_BLEND.py", 
>> line 74, in 
>> newname=string.join(["dataset_",sfx],"")
>> AttributeError: module 'string' has no attribute 'join'
> 
> whether I run BLEND from CCP4I or the command line.
> 
> Any help will be much appreciated!
> 
> Pedro Matias
> 
> -- 
> Industry and Medicine Applied Crystallography
> Macromolecular Crystallography Unit
> ___
> Phones : (351-21) 446-9100 Ext. 1669
> (351-21) 446-9669 (direct)
> Fax   : (351-21) 441-1277 or 443-3644
> 
> email : mat...@itqb.unl.pt
> 
> http://www.itqb.unl.pt/research/biological-chemistry/industry-and-medicine-applied-crystallography
> http://www.itqb.unl.pt/labs/macromolecular-crystallography-unit
> 
> Mailing address :
> Instituto de Tecnologia Quimica e Biologica António Xavier
> Universidade Nova de Lisboa
> Av. da República
> 2780-157 Oeiras
> PORTUGAL
> 
> ITQB NOVA, a great choice for your PhD
> https://youtu.be/de6j-aaTWNQ
> 
> Master Programme in Biochemistry for Health
> https://youtu.be/UKstDCFjYI8
> 
> 
> 
> 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/


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




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] Multiplicity is more than 20

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Prasun

You just measured the reflections a lot. 33 is fine. More likely even with 
cubic space groups

I’d love to know where you got the idea of the limit from. I have data sets 
with more than 100 fold multiplicity

The R conversation I’ll leave to others

Best wishes Graeme

On 19 Sep 2022, at 20:32, Prasun Kumar  wrote:


Hi All:

I have collected a dataset for a crystal of a 30 residues long helical peptide 
that makes a trimer in the solution. I also solved the structure to get a 
trimer. My issues start when I start preparing for a deposition.

Details about the data:

space group: I 21 3
Resolution: 1.6
Current Rfree/ Rwork: 0.21/0.19

Problems:
According to Aimless, Multiplicity: 33.9, and I understand that the value 
should be less than or equal to 20. Does it mean that I have a lot of random 
noise or ice rings or something similar?
For the inner shell, R work is also higher than R free.

Please guide me in solving the above issue.

Thank You
Prasun




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

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




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] Lower b-factors with increasing T

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Harry,

You’re not wrong - “conventional wisdom” these days is pointing to CC of about 
0.3 but I suspect that the difference is pretty modest in general

However, in the case, the difference could have an impact as the higher 
resolution reflections may have something to say about the overall B factors

I also wondered about the order of the data collection in this case, since 
there will probably be a certain amount of radiation damage across this number 
of data sets at non-cryo temperatures

Best wishes Graeme

> On 8 Sep 2022, at 10:21, Harry Powell 
> <193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote:
> 
> hi folks
> 
> I’ve been away from data processing for a while, but am I alone in thinking 
> that scaling to ~0.6 CC 1/2 cutoff might be ignoring a lot of useful data? I 
> seem to remember that AutoProc and xia2.multiplex use a default of >= 0.3.
> 
> Harry
> 
>> On 7 Sep 2022, at 19:46, Matt McLeod  wrote:
>> 
>> Hi everyone,
>> 
>> I have a series of datasets at 253K (~2.0A), 273K (2.0A), 293K (2.0A), 313K 
>> (2.2A) and I am curious as to the details in determining B-factors.
>> 
>> I have treated these datasets more-or-less identically for comparison's 
>> sake.  I used DIALS to index, integrate, and scale the data.  I scaled the 
>> data to a ~0.6 CC1/2 cutoff.  
>> 
>> After fully refining the datasets, there is an odd trend with respect to 
>> temperature (from what has been previously published) and I assume that this 
>> is because of "behind-the-scenes" computation rather than a biophysical 
>> observation.  The B-factors slightly decrease from 252-293K, and then 
>> significantly drop at 313K.  The maps look pretty well identical across the 
>> datasets.
>> 
>> 253K - 53.8 A^2
>> 273K - 48.4 A^2
>> 293K - 45.5 A^2
>> 313K - 18.6 A^2
>> 
>> I compared the wilson intensity plots from DIALS scaling for 273K and 313K 
>> and they are very comparable.
>> 
>> I am looking for suggestions as to where to look at how these b-factors are 
>> selected or how to validate that these B-factor are or are not accurate.  
>> Also, any relevant literature would be welcomed.  From what I have read, 
>> there is a general trend that as T increase, the atoms have more thermal 
>> energy which raises the b-factors and this trend is universal when comparing 
>> datasets from different temperatures.
>> 
>> Thank you and happy to supply more information if that is helpful,
>> Matt
>> 
>> 
>> 
>> 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/


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




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] Lower b-factors with increasing T

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Matt,

You mention that you process with DIALS - one thing I would recommend is 
scaling all the data together then merging each temperature point separately - 
I could do with preparing a HOWTO on this [1] - this would then mean that they 
are being scaled to be as similar as possible before you start which should 
then mean what you observe in terms of e.g. but B factor becomes relatively 
more meaningful (this could be a point of debate) 

But in general, if you are looking for differences between A and B first 
scaling them together to minimise external variation is useful. This is how 
things were done in prehistoric times with e.g. MIRAS, using scaleit

All the best Graeme

[1] if I get a quiet half hour I will do this later

> On 7 Sep 2022, at 19:46, Matt McLeod  wrote:
> 
> Hi everyone,
> 
> I have a series of datasets at 253K (~2.0A), 273K (2.0A), 293K (2.0A), 313K 
> (2.2A) and I am curious as to the details in determining B-factors.
> 
> I have treated these datasets more-or-less identically for comparison's sake. 
>  I used DIALS to index, integrate, and scale the data.  I scaled the data to 
> a ~0.6 CC1/2 cutoff.  
> 
> After fully refining the datasets, there is an odd trend with respect to 
> temperature (from what has been previously published) and I assume that this 
> is because of "behind-the-scenes" computation rather than a biophysical 
> observation.  The B-factors slightly decrease from 252-293K, and then 
> significantly drop at 313K.  The maps look pretty well identical across the 
> datasets.
> 
> 253K - 53.8 A^2
> 273K - 48.4 A^2
> 293K - 45.5 A^2
> 313K - 18.6 A^2
> 
> I compared the wilson intensity plots from DIALS scaling for 273K and 313K 
> and they are very comparable.
> 
> I am looking for suggestions as to where to look at how these b-factors are 
> selected or how to validate that these B-factor are or are not accurate.  
> Also, any relevant literature would be welcomed.  From what I have read, 
> there is a general trend that as T increase, the atoms have more thermal 
> energy which raises the b-factors and this trend is universal when comparing 
> datasets from different temperatures.
> 
> Thank you and happy to supply more information if that is helpful,
> Matt 
> 
> 
> 
> 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/


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



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] DIALS 3.11 release: graphical utilities broken

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear all,

Updated release at https://dials.github.io/installation.html - 3.11.1 - now 
based on Python 3.9.13 - with  working graphical utilities

Sorry to those who stubbed their toes on this, many thanks to my colleagues for 
fixing this on 1st day back :-)

All the best Graeme

On 30 Aug 2022, at 16:31, Winter, Graeme (DLSLtd,RAL,LSCI) 
<6a19cead4548-dmarc-requ...@jiscmail.ac.uk<mailto:6a19cead4548-dmarc-requ...@jiscmail.ac.uk>>
 wrote:

Hello everyone including brave souls who are keen to use the latest greatest 
version of DIALS - the recently released 3.11

Sorry

Please don’t

We have had a couple of reports of issues with the graphical utilities in here 
caused by upstream changes in Python which have completely broken the graphical 
libraries on which we depend

Locally detailed at

https://github.com/dials/dials/issues/2216

For anyone who wants to see the gory details which are a side-effect of

https://github.com/python/cpython/issues/82180

As this is in our graphical interface tools it is not subject to automated 
testing and it would appear that those of us who are developing on 3.10 did not 
stumble across the problem

We will make a .1 release in the next couple of days - it would appear that the 
nightly builds are also affected by the same issue.

In the meantime I recommend people download the previous latest release 3.10.3

https://github.com/dials/dials/releases/tag/v3.10.3

I would like to emphasise that the algorithms are still fine (I believe) this 
is just an error with the viewers but fixing this in the longer term could be a 
substantial body of work.

For those who get their DIALS from CCP4 you will be fine as that is still on 
Python 3.7 or 3.8 so will not be affected by these issues.

Best wishes 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




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] DIALS 3.11 release: graphical utilities broken

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hello everyone including brave souls who are keen to use the latest greatest 
version of DIALS - the recently released 3.11

Sorry

Please don’t

We have had a couple of reports of issues with the graphical utilities in here 
caused by upstream changes in Python which have completely broken the graphical 
libraries on which we depend

Locally detailed at

https://github.com/dials/dials/issues/2216

For anyone who wants to see the gory details which are a side-effect of

https://github.com/python/cpython/issues/82180

As this is in our graphical interface tools it is not subject to automated 
testing and it would appear that those of us who are developing on 3.10 did not 
stumble across the problem

We will make a .1 release in the next couple of days - it would appear that the 
nightly builds are also affected by the same issue.

In the meantime I recommend people download the previous latest release 3.10.3

https://github.com/dials/dials/releases/tag/v3.10.3

I would like to emphasise that the algorithms are still fine (I believe) this 
is just an error with the viewers but fixing this in the longer term could be a 
substantial body of work.

For those who get their DIALS from CCP4 you will be fine as that is still on 
Python 3.7 or 3.8 so will not be affected by these issues.

Best wishes 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




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?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

This rang a bell to me last night, and I think you can derive this from first 
principles

If you assume an observation of N counts, you can calculate the probability of 
such an observation for a given Poisson rate constant X. If you then integrate 
over all possible value of X to work out the central value of the rate constant 
which is most likely to result in an observation of N I think you get X = N+1

I think it is the kind of calculation you can perform on a napkin, if memory 
serves

All the best Graeme

On 13 Oct 2021, at 16:10, Andrew Leslie - MRC LMB 
mailto:and...@mrc-lmb.cam.ac.uk>> wrote:

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 
mailto:ianj...@gmail.com>> 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 
mailto:jmhol...@lbl.gov>> 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

Re: [ccp4bb] Rmeas in DIALS?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Phil,

No argument, you _can_

The question is where it came from in this context, as the outer shell is 
positive in the text output but somehow -ve in i2 version of the same

Unless i2 recalculates merging stats?

All the best Graeme

On 1 Jul 2021, at 14:52, Phil Evans 
mailto:p...@mrc-lmb.cam.ac.uk>> wrote:

You can get a negative Rmeas in a shell where  is negative

Sent from my iPhone

On 1 Jul 2021, at 14:21, Winter, Graeme (DLSLtd,RAL,LSCI) 
mailto:graeme.win...@diamond.ac.uk>> wrote:

 Thanks for sending the logs

Looking at the output the negative R values don’t come from xia2 directly

For AUTOMATIC/DEFAULT/NATIVE OverallLow High
High resolution limit   1.012.741.01
Low resolution limit   36.95   36.971.03
Completeness   68.672.216.3
Multiplicity3.4 4.0 1.1
I/sigma 6.811.0 0.6
Rmerge(I) 0.127   0.131   1.543
Rmerge(I+/-)  0.121   0.127   1.173
Rmeas(I)  0.141   0.147   2.162
Rmeas(I+/-)   0.145   0.151   1.659
Rpim(I)   0.059   0.062   1.512
Rpim(I+/-)0.078   0.079   1.173
CC half   0.985   0.971   0.149
Wilson B factor  11.910
Anomalous completeness 45.757.6 1.8
Anomalous multiplicity  2.1 2.5 1.0
Anomalous correlation-0.106  -0.135   0.000
Anomalous slope   0.921
dF/F  0.079
dI/s(dI)  0.699
Total observations   1432839600 559
Total unique  418512397 494
Assuming spacegroup: P 41 21 2
Other likely alternatives are:
P 43 21 2
Unit cell:
 78.580  78.580  36.950
 90.000  90.000  90.000

While a 1990’s reviewer would have a hard time with those merging stats, I have 
seen worse and they seem internally consistent

I wonder, is ccp4i2 doing something itself which arrives at those numbers?

i2 devs - thoughts?

Thanks Graeme

On 1 Jul 2021, at 05:49, Winter, Graeme (DLSLtd,RAL,LSCI) 
mailto:graeme.win...@diamond.ac.uk>> wrote:

Something odd happening there - please could you send the text log off list? 
i.e. xia2.txt

Thanks Graeme

On 1 Jul 2021, at 00:58, Murpholino Peligro 
mailto:murpholi...@gmail.com>> wrote:

Why Rmeas is negative in DIALS output?


Thanks




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





--

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




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



--

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

Re: [ccp4bb] Rmeas in DIALS?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Thanks for sending the logs

Looking at the output the negative R values don’t come from xia2 directly

For AUTOMATIC/DEFAULT/NATIVE OverallLow High
High resolution limit   1.012.741.01
Low resolution limit   36.95   36.971.03
Completeness   68.672.216.3
Multiplicity3.4 4.0 1.1
I/sigma 6.811.0 0.6
Rmerge(I) 0.127   0.131   1.543
Rmerge(I+/-)  0.121   0.127   1.173
Rmeas(I)  0.141   0.147   2.162
Rmeas(I+/-)   0.145   0.151   1.659
Rpim(I)   0.059   0.062   1.512
Rpim(I+/-)0.078   0.079   1.173
CC half   0.985   0.971   0.149
Wilson B factor  11.910
Anomalous completeness 45.757.6 1.8
Anomalous multiplicity  2.1 2.5 1.0
Anomalous correlation-0.106  -0.135   0.000
Anomalous slope   0.921
dF/F  0.079
dI/s(dI)  0.699
Total observations   1432839600 559
Total unique  418512397 494
Assuming spacegroup: P 41 21 2
Other likely alternatives are:
P 43 21 2
Unit cell:
 78.580  78.580  36.950
 90.000  90.000  90.000

While a 1990’s reviewer would have a hard time with those merging stats, I have 
seen worse and they seem internally consistent

I wonder, is ccp4i2 doing something itself which arrives at those numbers?

i2 devs - thoughts?

Thanks Graeme

On 1 Jul 2021, at 05:49, Winter, Graeme (DLSLtd,RAL,LSCI) 
mailto:graeme.win...@diamond.ac.uk>> wrote:

Something odd happening there - please could you send the text log off list? 
i.e. xia2.txt

Thanks Graeme

On 1 Jul 2021, at 00:58, Murpholino Peligro 
mailto:murpholi...@gmail.com>> wrote:

Why Rmeas is negative in DIALS output?


Thanks




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





--

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




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 to process two datasets 45 degrees apart?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Process with the same starting orientation matrix in Mosflm, with XDS I would 
process one sweep then take the output of IDXREF and copy into the XDS.INP for 
second sweep using

https://xds.mr.mpg.de/html_doc/xds_parameters.html#UNIT_CELL_A-AXIS=

to ensure common axis definitions. Integrate separately then scale together. 
For completeness, with DIALS you can index both sweeps at the same time, 
integrate separately and then scale together.

Best wishes Graeme

On 1 Jul 2021, at 00:57, Murpholino Peligro 
mailto:murpholi...@gmail.com>> 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


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




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] Rmeas in DIALS?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Something odd happening there - please could you send the text log off list? 
i.e. xia2.txt

Thanks Graeme

On 1 Jul 2021, at 00:58, Murpholino Peligro 
mailto:murpholi...@gmail.com>> wrote:

Why Rmeas is negative in DIALS output?


Thanks




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




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




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] Should Rmerge be reported?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Tim,

can I explain? To be honest no! Other than old habits and all. Should converge 
to the same value in the end, so you have a valid point.

All the best Graeme



From: Tim Gruene
Sent: Thursday, June 10, 2021 14:02
To: Winter, Graeme (DLSLtd,RAL,LSCI)
Cc: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Should Rmerge be reported?

Hi Graeme,

could you explain why Rmeas does not serve the same purpose as Rmerge?
I guess Manfred (and others) have no objection to reporting Rmeas just
instead of Rmerge.

@ Christy: If one of my manuscript were rejected solely because Rmerge
was not mentioned, I would make a phone call to the boss if the editor.
Afterall, Rmerge can be recovered from the unmerged data, which ideally
you did deposit at the PDB.

Best,
Tim


On Thu, 10 Jun 2021 12:42:10 + "Winter, Graeme (DLSLtd,RAL,LSCI)"
 wrote:

> Once again I find myself jumping to the defence of this rather poor
> statistic!
>
> Yes, Rmerge is a very poor estimator of "data quality" and has many
> well published flaws related to multiplicity, but the low resolution
> Rmerge, if combined with a multiplicity > (say) 5, is a good
> indicator of whether the data set is "good" or there is something odd
> going on.
>
> For example, if you claim a 1.6A structure with an inner shell Rmerge
> of 0.11, 5-fold multiplicity and an overall I/sig(I) of 68 I would
> "smell a rat"
>
> To me it does have a value, as an unbiased estimator of your true
> unmerged I/sigma as it does not depend on any manipulation you have
> done to your sigmas. It is not a good estimator of where the
> resolution should be cut or any other decisions.
>
> The above situation could be an indicator that there was radiation
> damage, for example
>
> There are better ways of measuring damage - Rd, Rcp, ... but these
> are not commonplace graphs as I understand it. This little number in
> the middle of the table does give you that hint.
>
> So while I would say rejecting a paper because it was not included
> was very heavy handed, I would not like to see it erased from all
> papers either.
>
> All the best Graeme
> 
> From: CCP4 bulletin board  on behalf of
> Manfred S. Weiss  Sent: 10 June
> 2021 13:30 To: CCP4BB@JISCMAIL.AC.UK 
> Subject: Re: [ccp4bb] Should Rmerge be reported?
>
> Dear Cristy,
>
> this is really hilarious. And it just shows how attached
> some ppl are to outdated numbers. Against better
> knowledge.
>
> It has been shown many times that Rmerge is flawed
> at various levels.
>
> The only reason I can see to report it is to be backwards
> compatible. But of course, this is a really weak reason.
>
> I would love to see it disappear.
>
> All the best
> Manfred
>
> Am 10.06.2021 um 14:25 schrieb Maria Cristina Nonato:
> Dear Colleagues
> Hope to find you all well and healthy.
>
> I have a question regarding Rmerge. In recent years, we have
> published our crystallographic structures in highly respected
> journals using CC1/2, I/sigma(I), completeness and multiplicity as
> quality parameters for our diffraction data.
>
> Recently this year, We submitted a paper using the same strategy, but
> one of the reviewers asked us to provide the Rmerge, arguing that
> providing this data was compulsory and it was important to estimate
> radiation damage.
>
> We replied to the editor arguing that Rmerge should not be used as a
> quality parameter, as suggested by more recent literature, such as
> the article published by Karplus and Diederichs
> (10.1016/j.sbi.2015.07.003). We also argued that there are modern and
> efficient methods to estimate radiation damage (
> doi.org/10.1107/S1600576718005241<http://doi.org/10.1107/S1600576718005241>;
> doi.org/10.1107/S0907444909040177<http://doi.org/10.1107/S0907444909040177>).
> It is my opinion that an experienced crystallographer can even
> monitor radiation damage over the course of data processing.
>
> And our paper was rejected  due to the fact I did not
> provide Rmerge which I certainly could have done If I found necessary.
>
> Journals like Nature ((https://www.nature.com › documents ›
> nr-tables-xray<https://www.google.com/url?sa=t=j==s=web==2ahUKEwiigtb19uHwAhWS3YUKHSB1AdkQFjABegQIAxAD=https%3A%2F%2Fwww.nature.com%2Fdocuments%2Fnr-tables-xray.doc=AOvVaw1RbfYvNeiEM07FBEOohMig>)
> and even IUCr Journals
> (https://journals.iucr.org/f/services/structuralcommunications/)
> still list Rmerge as a data to be reported. I always took this as a
> suggestion since there are people still using Rmerge for data cutoff,
> but I never took this as if Rmerge was a compulsory data

Re: [ccp4bb] Should Rmerge be reported?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear Manfred,

I completely agree. However this is not routinely reported.

The discussion is of removing one indicator of this signal, rather than 
replacing it with a superior measure - the latter is something I would more 
actively support however would involve adding new stuff which is an uphill 
battle.

All the best Graeme

From: Manfred S. Weiss 
Sent: 10 June 2021 13:43
To: Winter, Graeme (DLSLtd,RAL,LSCI) ; 
CCP4BB@JISCMAIL.AC.UK 
Subject: Re: [ccp4bb] Should Rmerge be reported?

Dear Graeme,

a better number to look at is Isa. Instead of low resolution Rmerge.
Seriously. We monitor that to assess beamline performance.

Cheers, Manfred

Am 10.06.2021 um 14:42 schrieb Winter, Graeme (DLSLtd,RAL,LSCI):
Once again I find myself jumping to the defence of this rather poor statistic!

Yes, Rmerge is a very poor estimator of "data quality" and has many well 
published flaws related to multiplicity, but the low resolution Rmerge, if 
combined with a multiplicity > (say) 5, is a good indicator of whether the data 
set is "good" or there is something odd going on.

For example, if you claim a 1.6A structure with an inner shell Rmerge of 0.11, 
5-fold multiplicity and an overall I/sig(I) of 68 I would "smell a rat"

To me it does have a value, as an unbiased estimator of your true unmerged 
I/sigma as it does not depend on any manipulation you have done to your sigmas. 
It is not a good estimator of where the resolution should be cut or any other 
decisions.

The above situation could be an indicator that there was radiation damage, for 
example

There are better ways of measuring damage - Rd, Rcp, ... but these are not 
commonplace graphs as I understand it. This little number in the middle of the 
table does give you that hint.

So while I would say rejecting a paper because it was not included was very 
heavy handed, I would not like to see it erased from all papers either.

All the best Graeme

From: CCP4 bulletin board <mailto:CCP4BB@JISCMAIL.AC.UK> 
on behalf of Manfred S. Weiss 
<mailto:manfred.we...@helmholtz-berlin.de>
Sent: 10 June 2021 13:30
To: CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK> 
<mailto:CCP4BB@JISCMAIL.AC.UK>
Subject: Re: [ccp4bb] Should Rmerge be reported?

Dear Cristy,

this is really hilarious. And it just shows how attached
some ppl are to outdated numbers. Against better
knowledge.

It has been shown many times that Rmerge is flawed
at various levels.

The only reason I can see to report it is to be backwards
compatible. But of course, this is a really weak reason.

I would love to see it disappear.

All the best
Manfred

Am 10.06.2021 um 14:25 schrieb Maria Cristina Nonato:
Dear Colleagues
Hope to find you all well and healthy.

I have a question regarding Rmerge. In recent years, we have published our 
crystallographic structures in highly respected journals using CC1/2, 
I/sigma(I), completeness and multiplicity as quality parameters for our 
diffraction data.

Recently this year, We submitted a paper using the same strategy, but one of 
the reviewers asked us to provide the Rmerge, arguing that providing this data 
was compulsory and it was important to estimate radiation damage.

We replied to the editor arguing that Rmerge should not be used as a quality 
parameter, as suggested by more recent literature, such as the article 
published by Karplus and Diederichs (10.1016/j.sbi.2015.07.003). We also argued 
that there are modern and efficient methods to estimate radiation damage ( 
doi.org/10.1107/S1600576718005241<http://doi.org/10.1107/S1600576718005241>; 
doi.org/10.1107/S0907444909040177<http://doi.org/10.1107/S0907444909040177>). 
It is my opinion that an experienced crystallographer can even  monitor 
radiation damage over the course of data processing.

And our paper was rejected  due to the fact I did not provide 
Rmerge which I certainly could have done If I found necessary.

Journals like Nature ((https://www.nature.com › documents › 
nr-tables-xray<https://www.google.com/url?sa=t=j==s=web==2ahUKEwiigtb19uHwAhWS3YUKHSB1AdkQFjABegQIAxAD=https%3A%2F%2Fwww.nature.com%2Fdocuments%2Fnr-tables-xray.doc=AOvVaw1RbfYvNeiEM07FBEOohMig>)
 and even IUCr Journals 
(https://journals.iucr.org/f/services/structuralcommunications/) still list 
Rmerge as a data to be reported. I always took this as a suggestion since there 
are people still using Rmerge for data cutoff, but I never took this as if 
Rmerge was a compulsory data to be reported.

I would like to hear the opinion of this community. Should we compulsorily 
report Rmerge?  If so, Why?

Cheers,

Cristy
--
Cristina Nonato
Associate Professor
Laboratório de Cristalografia de Proteínas
Faculdade de Ciências Farmacêuticas de Ribeirão Preto
University of São Paulo





To unsubscribe from the CCP4BB list, click the following link:
https:

Re: [ccp4bb] Should Rmerge be reported?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Once again I find myself jumping to the defence of this rather poor statistic!

Yes, Rmerge is a very poor estimator of "data quality" and has many well 
published flaws related to multiplicity, but the low resolution Rmerge, if 
combined with a multiplicity > (say) 5, is a good indicator of whether the data 
set is "good" or there is something odd going on.

For example, if you claim a 1.6A structure with an inner shell Rmerge of 0.11, 
5-fold multiplicity and an overall I/sig(I) of 68 I would "smell a rat"

To me it does have a value, as an unbiased estimator of your true unmerged 
I/sigma as it does not depend on any manipulation you have done to your sigmas. 
It is not a good estimator of where the resolution should be cut or any other 
decisions.

The above situation could be an indicator that there was radiation damage, for 
example

There are better ways of measuring damage - Rd, Rcp, ... but these are not 
commonplace graphs as I understand it. This little number in the middle of the 
table does give you that hint.

So while I would say rejecting a paper because it was not included was very 
heavy handed, I would not like to see it erased from all papers either.

All the best Graeme

From: CCP4 bulletin board  on behalf of Manfred S. Weiss 

Sent: 10 June 2021 13:30
To: CCP4BB@JISCMAIL.AC.UK 
Subject: Re: [ccp4bb] Should Rmerge be reported?

Dear Cristy,

this is really hilarious. And it just shows how attached
some ppl are to outdated numbers. Against better
knowledge.

It has been shown many times that Rmerge is flawed
at various levels.

The only reason I can see to report it is to be backwards
compatible. But of course, this is a really weak reason.

I would love to see it disappear.

All the best
Manfred

Am 10.06.2021 um 14:25 schrieb Maria Cristina Nonato:
Dear Colleagues
Hope to find you all well and healthy.

I have a question regarding Rmerge. In recent years, we have published our 
crystallographic structures in highly respected journals using CC1/2, 
I/sigma(I), completeness and multiplicity as quality parameters for our 
diffraction data.

Recently this year, We submitted a paper using the same strategy, but one of 
the reviewers asked us to provide the Rmerge, arguing that providing this data 
was compulsory and it was important to estimate radiation damage.

We replied to the editor arguing that Rmerge should not be used as a quality 
parameter, as suggested by more recent literature, such as the article 
published by Karplus and Diederichs (10.1016/j.sbi.2015.07.003). We also argued 
that there are modern and efficient methods to estimate radiation damage ( 
doi.org/10.1107/S1600576718005241; 
doi.org/10.1107/S0907444909040177). 
It is my opinion that an experienced crystallographer can even  monitor 
radiation damage over the course of data processing.

And our paper was rejected  due to the fact I did not provide 
Rmerge which I certainly could have done If I found necessary.

Journals like Nature ((https://www.nature.com › documents › 
nr-tables-xray)
 and even IUCr Journals 
(https://journals.iucr.org/f/services/structuralcommunications/) still list 
Rmerge as a data to be reported. I always took this as a suggestion since there 
are people still using Rmerge for data cutoff, but I never took this as if 
Rmerge was a compulsory data to be reported.

I would like to hear the opinion of this community. Should we compulsorily 
report Rmerge?  If so, Why?

Cheers,

Cristy
--
Cristina Nonato
Associate Professor
Laboratório de Cristalografia de Proteínas
Faculdade de Ciências Farmacêuticas de Ribeirão Preto
University of São Paulo





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


--
Dr. Manfred S. Weiss
Macromolecular Crystallography
Helmholtz-Zentrum Berlin
Albert-Einstein-Str. 15
D-12489 Berlin
Germany



Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Volkmar Dietz, stv. Vorsitzende Dr. Jutta 
Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (Sprecher), Prof. Dr. Jan Lüning, Thomas 
Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
14109 Berlin
Deutschland



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

-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee 

Re: [ccp4bb] Reprocessing images collected on an Eiger2 detector using Xia2Dials on CCP4i2's GUI

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi All,

Sorry for the slow response - holiday season & all (I am sure many of us needed 
a break at the end of 2020)

Windows is currently not super well supported for xia2 / DIALS work and won’t 
work at all for xia2 / XDS for the simple reason that XDS is not available for 
the platform (hence absence of durin plugin for Windows mentioned elsewhere in 
this thread)

Your data are from 2019 I would guess from the log text

In this case I would honestly suggest that the best method to process this data 
is to either -
 - work on a UNIX based system
or
 - restage the data to Diamond and process there

I’m happy to help (off list) with the details of this if it would help

We probably should invest some effort in properly supporting Windows for xia2 / 
DIALS - however there are a bunch of rather nasty jobs to do in making this 
possible and it’s never “the most important thing” sorry :-(

Happy new year & best wishes Graeme

On 22 Dec 2020, at 16:53, Irwin Selvam 
mailto:irwin.sel...@postgrad.manchester.ac.uk>>
 wrote:

Hi,

I'd like to reprocess some data that were collected on an Eiger2 detector at 
Diamond with Xia2Dials using CCP4i2's GUI. I'm running CCP4i2 on a 64-bit 
Windows 10 machine. The data were processed successfully at Diamond with no 
obvious pathologies, the high resolution limit was just a little generous. The 
folder in question contains a Diamond specific file (.nsx extension), two image 
files (.h5), a header (.cbf), a master (.h5) and meta file (.h5). I've tried 
pointing Xia2 to the folder itself (which works when processing data collected 
on PILATUS detectors) and each of the files contained therein (except the 
Diamond specific file). Each time this results in the error " -ERROR- None:56 
Error in wrapper xia2_dials 0.0:: External process exited with exit code != 0 
Process: C:\CCP4-7\7.1\bin\xia2.bat -ERROR- None:47 Error in wrapper xia2_dials 
0.0:: Error in checking external process after completion exit status and code: 
0 1". I've attached the error, debug etc files for a representative 'run' to 
this email. Which files do I need to point xia2 towards to get it to run? Any 
help would be appreciated.

All the best,

Irwin


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



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




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] Apple Silicon / XQuartz / X11 / CCP4

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Antony

In theory (TM) things should just work with Rosetta 2 - how well they work is a 
matter for some debate and I think there will be a lot of eyes on non-Apple 
benchmarks of this system. 

I would guess though that it will be inevitable that we (DIALS, CCP4, the 
community, …) need to natively support the system eventually as these are 
pretty popular type machines. Also, I suspect the M2 or whatever will appear in 
higher end MacBook pro’s could be very interesting

I’d certainly say ignoring the new architecture would be a poor choice…

Cheers Graeme

> On 11 Nov 2020, at 09:21, Antony Oliver  wrote:
> 
> Perhaps this is a little too soon, but does anyone know if the new M1 
> system-on-a-chip will continue to run XQuartz/X11 + the CCP4 program suite + 
> other crystallography / EM software? Will CCP4 continue to support the 
> platform?
> 
> (a quick check of the GitHub page indicates that there is already an ARM64 
> implementation of XQuartz)
> 
> I am not in a rush to purchase the newly announced computers, but am keen to 
> understand if we are going to need to future-proof ourselves when the entire 
> family moves over to the new hardware.
> 
> With thanks,
> 
> Antony.
> 
> 
> 
> 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/


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




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] CCP4 tutorials (files)

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Rafael,

http://legacy.ccp4.ac.uk/docs.php

-> tutorials

Looks like there’s something very broken with the style sheets or something but 
the information does appear to be available

The links to tar files of data appear to work

Best wishes Graeme

On 30 Jul 2020, at 15:10, Rafael Marques 
mailto:rafael_mmsi...@hotmail.com>> wrote:

Hello folks.

During the quarantine I am trying to use some softwares on CCP4 that I have 
never used before and also to learn how to solve structures differently than 
the usual MR (for me). However, the ccp4 tutorial website is down and error 404 
is everywhere. Does anybody know a link where I can find files for doing SAD, 
MAD, MR, SIRAS and so on?

Many thanks in advance

__

Rafael Marques da Silva
Mestrando em Física Biomolecular
Universidade de São Paulo

Bacharel em Ciências Biológicas
Universidade Federal de São Carlos

phone: +55 16 99766-0021

   "A sorte acompanha uma mente bem treinada"





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


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




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] Accessing full list of programs in CCP4I2

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Folks,

Re: docs for elderly programs

cd $CBIN/html

In here you will find the ccp4 program docs probably going back ~ 20+ years for 
the old programs - for _your_ version of ccp4

It’s probably got greater coverage on the old command line stuff than the 
newfangled i2 things

Cheers Graeme (who still uses scripts to run ccp4 things)

On 8 Jul 2020, at 19:17, Lau Kelvin 
mailto:kelvin@epfl.ch>> wrote:

I didn’t expect it to be so lively!

I completely understand the reasons why there are changes, it looks quite good 
and I think it benefits new users greatly. Its just for us “old-fashioned” folk 
it just becomes a bit tedious to find out where the programs are now, as long 
as they are there!

However, is there a link anywhere to the old 7.0 versions? I installed 7.1 but 
removed 7.0…. I found one on google, but it led me back to 7.1.



On Jul 7, 2020, at 9:12 PM, Eleanor Dodson 
<176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk>
 wrote:

I really didnt mean to start this discussion - actually you did, Lau! I am so 
grateful to the modern developers who have provided GUIs to guide our work, and 
now semi-automated pipelines which mean structures can be solved routinely and 
quickly..

 Certainly it is easy enough to bypass fft to generate a map, and COOT has many 
many more facilities than the tools I quoted..
But there are some common sense oversights in all software, and it is often 
easier to find an outdated procedure to get round the difficulties than to 
influence the developers to alter their code.
One example is software which put solutions for heavy atoms, or molecular 
replacement distant from the origin . Crystallographically this is irrelevant 
but it can lead to problems in visualisation or building assemblies..
Enough - Eleanor

Cheers anyway

On Tue, 7 Jul 2020 at 19:36, Dominika Borek 
mailto:domin...@work.swmed.edu>> wrote:

I remember when I started using ccp4 programs, that frustration of writing 
scripts to run programs, and a relief when the first version of the GUI became 
available.  I have to say that there is a joy in knowing that students in 2020 
will have to also write scripts to run unsupported programs (who would guess 
that fft will be the one of those?).

Does CCP4online provide an access to all these programs? I was hesitant to 
switch, but it might be the push I needed.

What about discussing these "not taken lightly" decisions on this forum with, 
you know, users... Asking couple thousands people with combined expertise of a 
few thousands of "X-ray crystallography" years, should provide deeper insight 
into needs of community, than asking programmers around.

D.

On 2020-07-07 12:17 PM, Eleanor Dodson wrote:

I dont expect anyone to install these in the interface, and indeed if COOT told 
you the symmetry operators in a comprehensive way the distang style searches 
would be almost redundant .. But sometimes it helps to have textual 
information.. clearer andeasier to record than graphical messages..
E



On Tue, 7 Jul 2020 at 17:42, Christian Roth 
mailto:christianroth...@gmail.com>> wrote:
I understand that one is used to the programs one is familiar with and Eleanor 
especially is very fond of these things, but there are several things which can 
be done for example in Coot (symmetry coordinates etc) . It is just another way 
to do it. I had the chance and pleasure to work for a while with the 
programmers of some of these programs in one building and such decisions are 
not taken lightly. But one cannot support all programs and write for every 
program interfaces or even keep two interfaces alive. There are just not enough 
people and money to do that. Also most scientific programmers don't get paid to 
keep the things just running. Would it be better to have also programmers to 
keep legacy up to date and write and update GUI's, maybe? But again someone 
needs to pay for that.
Just my 2 cents.

Cheers
Christian


On Tue, Jul 7, 2020 at 6:30 PM Oganesyan, Vaheh 
mailto:vaheh.oganes...@astrazeneca.com>> wrote:
... and how all these changes being justified?

From: CCP4 bulletin board mailto:CCP4BB@JISCMAIL.AC.UK>> 
On Behalf Of Eleanor Dodson
Sent: Tuesday, July 7, 2020 12:25 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Accessing full list of programs in CCP4I2

Yes - there are things I use all the time which are not part of the CCP4I2 list
pdbset to generate symmetry equivalents  or find the centre of mass etc etc
coordconv to turn orthogonal coordinates to fractional - after all we are 
crystallographers and need to relate models to unit cells..
distang to do a quick check on crystal contacts..
nd there must be more..
Eleanor

On Tue, 7 Jul 2020 at 17:16, Palm, Gottfried 
mailto:p...@uni-greifswald.de>> wrote:
For occasions like Laus, it would be useful to further on have access to the
CCP4 v7.0 Program Documentation,
even if the programs are not updated as Christian 

Re: [ccp4bb] Relaying a remote data collection on using moodle collaborate or Microsoft Teams

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi James,

At your offline suggestion I tried this myself and observe the same fit 
inducing flashing - however when I shared the desktop (which had a full-screen 
NX session running) it worked fine

The performance seems good enough to be able to follow along with data 
collection at the very least

Best wishes Graeme

> On 3 Jul 2020, at 09:44, Sandy, James (DLSLtd,RAL,LSCI) 
>  wrote:
> 
> Hi all,
> 
> I have had problems trying to share my screen using Teams when using the NX 
> client. I have experienced the screen flashing in a manner which may induce 
> fits! This may be related to sharing a window rather than the whole desktop 
> but something to be aware of. I have taken to using Zoom if I want to work 
> with others sharing an NX session.
> 
> Cheers,
> 
> James
> 
> 
> -Original Message-----
> From: CCP4 bulletin board  On Behalf Of Winter, Graeme 
> (DLSLtd,RAL,LSCI)
> Sent: 03 July 2020 09:33
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Relaying a remote data collection on using moodle 
> collaborate or Microsoft Teams
> 
> Hi Nick
> 
> I’ll offer a vote in favour of teams, as it is possible with the desktop 
> application to hand over control as well for a shared window (e.g. NX) so 
> your student could perform the collection themselves under your supervision 
> rather than just watching.
> 
> I’ve not tried teams + NX as a combination but I can see no reason why this 
> would not work, it’s not like the network load will be much different to 
> watching a room full of happy faces… you could also try this out in advance, 
> connecting to nx.diamond for e.g. processing and confirming that the screen 
> share works so you lose no time on data collection day. 
> 
> FWIW I prefer zoom for meetings as it’s got better sound & copes better with 
> large groups (IMHO) however for small groups / 1:1 teams has worked quite 
> well in my experience, and I was particularly impressed with the screen 
> sharing. 
> 
> Best wishes Graeme
> 
> 
> 
>> On 3 Jul 2020, at 09:18, Nicholas Keep  wrote:
>> 
>> We are going to be doing a data collection for an MRes student at Diamond in 
>> the next couple of weeks.  These are his first crystals.  It would be good 
>> if he could be involved in watching it.
>> 
>> I was wondering if anyone had tried sharing screen and voice via moodle 
>> collaborate or Microsoft Teams while doing a data collection?  Zoom is 
>> deprecated by our institution but if anyone had succeeded on zoom that would 
>> also be interesting.
>> 
>> I am on Virgin media 100 MB broadband which is pretty much achieving that 
>> (upload is only around 9 MB though).
>> 
>> Alternatively we can try and set him up to connect via nx and watch, but 
>> that would lose the sound connection unless I have a phone tucked under my 
>> chin.
>> 
>> We could just record my screen and sound and he could watch later.
>> 
>> Any tips?
>> 
>> Best wishes
>> 
>> Nick
>> 
>> 
>> 
>> --
>> Prof Nicholas H. Keep
>> Executive Dean of School of Science
>> Professor of Biomolecular Science
>> Crystallography, Institute for Structural and Molecular Biology, 
>> Department of Biological Sciences Birkbeck,  University of London, 
>> Malet Street, Bloomsbury LONDON WC1E 7HX
>> 
>> Dean Email;  scid...@bbk.ac.uk
>> Dept email n.k...@mail.cryst.bbk.ac.uk
>> Telephone 020-7631-6852  (Room G54a Office)
>> 020-7631-6800  (Department Office)
>> Fax   020-7631-6803
>> If you want to access me in person you have to come to the 
>> crystallography entrance and ring me or the department office from the 
>> internal phone by the door
>> 
>> ##
>> ##
>> 
>> 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/
> 
> 
> --
> 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

Re: [ccp4bb] [EXTERNAL] Re: [ccp4bb] number of frames to get a full dataset?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Thanks Ian - I think you raise some excellent points - while I think the 
general reader (TM) would understand that redundancy and multiplicity mean 
broadly the same thing in Table 1, I think having program developers document 
_precisely_ what they mean by those values would be very valuable. I also look 
hard at “completeness” which seems to vary from one program to the next and 
cause some confusion to end users.

I appreciate that some of this effort will also land on my desk and am happy to 
practice that which I preach

Best wishes Graeme

On 2 Jul 2020, at 21:05, Ian Tickle 
mailto:ianj...@gmail.com>> wrote:


Well I very much doubt that many software developers are going to trawl through 
all their code, comments, output statements & documentation to change 
'redundancy' or 'multiplicity' to 'MPR' or whatever terminology is agreed on 
(assuming of course we do manage to come to an agreement, which I doubt).  And 
good luck with persuading wwPDB to change 'redundancy' in their mmCIF 
dictionary!  That would be not only pointless but also a lot of work, partly 
because terms get abbreviated in code and in outputs (e.g. to 'redund' in mine, 
or 'mult').  And don't say I can keep the code & comments the same and only 
change the outputs and documentation: that will really tax my brain!  Also 
don't say this need only apply to new code: no code is ever completely new, and 
mixing up old & new terminology would be a disaster waiting to happen!  Also it 
won't end there: someone will always find terminology that they disagree with: 
I can think of plenty cans of worms that we could open, but I think one is 
already one too many!

By the way, "measurements per reflection" won't float, because some 
measurements will be rejected as outliers (that's why we need redundancy! - as 
opposed to simply measuring intensities for longer).  What I call redundancy is 
"the count of _contributing_ measurements per reflection" (CCMPR, sigh).  
Personally I think that adding one more term is going to confuse things even 
more since if I'm right most people will continue to use the old terms in 
parallel anyway.

IMO we should all be free to use the terminology we are most comfortable with, 
and it's up to the receivers of the information to perform the translation.  
That's how it always has been, and IMO always will be.  Of course it behoves 
(behooves?) the sender to point to or make available any necessary translation 
tools, such as a dictionary or glossary, but once that is done it is the 
responsibility of the receiver to make use of those tools.  Even better if you 
can point to formally-published information (i.e. book or peer-reviewed paper), 
since information on the web is so ephemeral.  As a receiver of information 
myself that's what my brain is doing constantly, i.e. converting others' 
terminology into concepts my brain can process.  If I'm forced to write code 
using a different set of terms it's inevitable that I will unconsciously lapse 
into my old bad ways and I'll end up with a dog's breakfast!  If I'm constantly 
having to convert my terminology into some standardised (standardized?) 
terminology before committing it to code, I'm going to use up what little 
brainpower I have left!

The absolutely critical thing surely is to DEFINE all terms that might be 
unfamiliar or ambiguous (yes Bernhard, I abhor a definitional vacuum for this 
very reason!).  That way the developers feel comfortable and the users can 
understand what's going on.  I'm very happy to put my head on the chopping 
block and add redundancy, multiplicity and whatever other terms people find 
unfamiliar or ambiguous in my outputs or documentation to my 
Glossary.  
Note that this covers only terms used on the STARANISO server; it is by no 
means intended as a replacement for the IUCr's Online Dictionary of 
Crystallography (or any other dictionary for that matter).

By the way, James, you left out my favourite (favorite?): "I could/couldn't 
care less", the positive one of which I always find illogical (if one could 
care less that means the amount of caring must be strictly positive since a 
negative amount is meaningless, whereas if one couldn't care less the amount of 
caring must already be exactly zero, which is surely what the expression is 
meant to convey).  I'm not suggesting at all that I don't care, quite the 
opposite: I think it's vital that terminology is universally understood 
("define your terms, Sir, or we'll never agree").

So my 2p's worth is: carry on as we are, but please, please, please DEFINE (and 
only argue about the definitions!).

https://www.brainyquote.com/quotes/dylan_moran_557269?src=t_please_everyone

Cheers

-- Ian


On Thu, 2 Jul 2020 at 11:11, Harry Powell - CCP4BB 
<193323b1e616-dmarc-requ...@jiscmail.ac.uk>
 wrote:
Dear all

I’ve been persuaded that MPR is a useful name 

Re: [ccp4bb] Relaying a remote data collection on using moodle collaborate or Microsoft Teams

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Nick

I’ll offer a vote in favour of teams, as it is possible with the desktop 
application to hand over control as well for a shared window (e.g. NX) so your 
student could perform the collection themselves under your supervision rather 
than just watching.

I’ve not tried teams + NX as a combination but I can see no reason why this 
would not work, it’s not like the network load will be much different to 
watching a room full of happy faces… you could also try this out in advance, 
connecting to nx.diamond for e.g. processing and confirming that the screen 
share works so you lose no time on data collection day. 

FWIW I prefer zoom for meetings as it’s got better sound & copes better with 
large groups (IMHO) however for small groups / 1:1 teams has worked quite well 
in my experience, and I was particularly impressed with the screen sharing. 

Best wishes Graeme



> On 3 Jul 2020, at 09:18, Nicholas Keep  wrote:
> 
> We are going to be doing a data collection for an MRes student at Diamond in 
> the next couple of weeks.  These are his first crystals.  It would be good if 
> he could be involved in watching it.
> 
> I was wondering if anyone had tried sharing screen and voice via moodle 
> collaborate or Microsoft Teams while doing a data collection?  Zoom is 
> deprecated by our institution but if anyone had succeeded on zoom that would 
> also be interesting.
> 
> I am on Virgin media 100 MB broadband which is pretty much achieving that 
> (upload is only around 9 MB though).
> 
> Alternatively we can try and set him up to connect via nx and watch, but that 
> would lose the sound connection unless I have a phone tucked under my chin.
> 
> We could just record my screen and sound and he could watch later.
> 
> Any tips?
> 
> Best wishes
> 
> Nick
> 
> 
> 
> -- 
> Prof Nicholas H. Keep
> Executive Dean of School of Science
> Professor of Biomolecular Science
> Crystallography, Institute for Structural and Molecular Biology,
> Department of Biological Sciences
> Birkbeck,  University of London,
> Malet Street,
> Bloomsbury
> LONDON
> WC1E 7HX
> 
> Dean Email;   scid...@bbk.ac.uk
> Dept email n.k...@mail.cryst.bbk.ac.uk
> Telephone 020-7631-6852  (Room G54a Office)
>  020-7631-6800  (Department Office)
> Fax   020-7631-6803
> If you want to access me in person you have to come to the crystallography 
> entrance
> and ring me or the department office from the internal phone by the door
> 
> 
> 
> 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/


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




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] number of frames to get a full dataset?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Or, we could accept the fact that crystallographers are kinda used to 
multiplicity of an individual Miller index being different to multiplicity of 
observations, and in Table 1 know which one you mean?  Given that they add new 
information (at the very least to the scaling model) they are strictly not 
“redundant”.

The amount that anyone outside of methods development cares about the “epsilon” 
multiplicity of reflections is … negligible?

Sorry for chucking pragmatism into a dogmatic debate 

Cheerio Graeme

On 29 Jun 2020, at 23:36, Bernhard Rupp 
mailto:hofkristall...@gmail.com>> wrote:

I think it is time to escalate that discussion to crystallographic definition 
purists like Massimo or to a logical consistency proponent like Ian who abhors 
definitional vacuum 

Cheers, BR

From: CCP4 bulletin board mailto:CCP4BB@JISCMAIL.AC.UK>> 
On Behalf Of Andreas Förster
Sent: Monday, June 29, 2020 15:24
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] number of frames to get a full dataset?

I like to think that the reflections I carefully measured at high multiplicity 
are not redundant, which the dictionary on my computer defines as "not or no 
longer needed or useful; superfluous" and the American Heritage Dictionary as 
"exceeding what is necessary or natural; superfluous" and "needlessly 
repetitive; verbose".

Please don't use the term Needless repetitivity in your Table 1.  It sends the 
wrong message.  Multiplicity is good.

All best.


Andreas



On Tue, Jun 30, 2020 at 12:03 AM James Holton 
mailto:jmhol...@lbl.gov>> wrote:
I have found that the use of "redundancy" vs "multiplicity" correlates very 
well with the speaker's favorite processing software.  The Denzo/HKL program 
scalepack outputs "redundancy", whereas scala/aimless and other more 
Europe-centric programs output "multiplicity".

At least it is not as bad as "intensity", which is so ambiguous as to be almost 
useless as a word on its own.

-James Holton
MAD Scientist
On 6/24/2020 10:27 AM, Bernhard Rupp wrote:
> Oh, and some of us prefer the word 'multiplicity' ;-0
Hmmm…maybe not. ‘Multiplicity’ in crystallography is context sensitive, and not 
uniquely defined. It can refer to

  1.  the position multiplicity (number of equivalent sites per unit cell, aka 
Wyckoff-Multiplicity), the only (!) cif use of multiplicity
  2.  the multiplicity of the reflection, which means the superposition of 
reflections with the same d  (mostly powder diffraction)
  3.  the multiplicity of observations, aka redundancy.
While (a) and (b) are clearly defined, (c) is an arbitrary experimental number.
How from (a) real space symmetry follows (b) in reciprocal space (including the 
epsilon zones, another ‘multiplicity’) is explained here
https://scripts.iucr.org/cgi-bin/paper?a14080
and also on page 306 in BMC.
Too much multiplicity might create duplicity…
Cheers, BR

Jon Cooper

On 23 Jun 2020 22:04, "Peat, Tom (Manufacturing, Parkville)" 
mailto:tom.p...@csiro.au>> wrote:
I would just like to point out that for those of us who have worked too many 
times with P1 or P21 that even 360 degrees will not give you 'super' anomalous 
differences.
I'm not a minimalist when it comes to data- redundancy is a good thing to have.
cheers, tom

Tom Peat
Proteins Group
Biomedical Program, CSIRO
343 Royal Parade
Parkville, VIC, 3052
+613 9662 7304
+614 57 539 419
tom.p...@csiro.au


From: CCP4 bulletin board mailto:CCP4BB@JISCMAIL.AC.UK>> 
on behalf of 
0c2488af9525-dmarc-requ...@jiscmail.ac.uk
 
<0c2488af9525-dmarc-requ...@jiscmail.ac.uk>
Sent: Wednesday, June 24, 2020 1:10 AM
To: 
CCP4BB@JISCMAIL.AC.UKmailto:CCP4BB@JISCMAIL.AC.UK>>
Subject: Re: [ccp4bb] number of frames to get a full dataset?

Someone told me there is a cubic space group where you can get away with 
something like 11 degrees of data. It would be interesting if that's correct. 
These minimum ranges for data collection rely on the crystal being 
pre-oriented, which is unheard-of these days, although they can help if someone 
is nagging you to get off the beam line or if your diffraction fades quickly. 
Going for 180 degrees always makes sense for a well-behaved crystal, or 360 
degrees if you want super anomalous differences. Hope this helps a bit.
Jon Cooper

On 23 Jun 2020 07:29, Andreas Förster 
mailto:andreas.foers...@dectris.com>> wrote:
Hi Murpholino,

in my opinion (*), the question is neither number of frames nor degrees.  The 
only thing that matters to your crystal is dose.  How many photons does your 
crystal take before it dies?  Consequently, the question to ask is How best to 
use photons.  Some people have done exactly that.
https://doi.org/10.1107/S2059798319003528

All best.


Andreas


(*) Disclaimer:  I benefit when you use PILATUS or EIGER - but I want 

Re: [ccp4bb] Question about small molecule crystallography

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Jon

Ambiguous phrasing, perhaps - the detector has a maximum count rate, as events 
per second, and it is easy to exceed this with a good quality small molecule 
crystal on an undulator beamline thus under record the intensity of strong 
reflections

Best wishes Graeme

On 8 Jun 2020, at 20:55, bogba...@yahoo.co.uk<mailto:bogba...@yahoo.co.uk> 
wrote:

Re: "it turns out to be very very easy to exceed the count rate where the 
detector electronics can keep up."

Sorry if this is obvious, but I take it you mean "_can't_" keep up?

Jon Cooper

On 4 Jun 2020 13:06, "Winter, Graeme (DLSLtd,RAL,LSCI)" 
mailto:graeme.win...@diamond.ac.uk>> wrote:
Dear All,

A small word of caution regarding chemical crystallography on an MX-like 
beamline - if you have a bright source, a well diffracting crystal and a pixel 
array detector it is perfectly possible to lose counts in the strongest 
reflections without noticing - certainly without going over the nominal 
detector count limits if your mosaic spread is very small

At Diamond we faced this issue with i19, which is a dedicated chemical 
crystallography beamline on an undulator source, with a Pilatus 2 detector - it 
turns out to be very very easy to exceed the count rate where the detector 
electronics can keep up. This is somewhat less of a problem with Pilatus 3 and 
Eiger 2X detectors.

So: I would strongly suggest really turning down the intensity on the beam, use 
fine slicing and be prepared to check that the data are OK before removing your 
sample. You can solve and refine the structure with e.g. SHELX and get an F^2 
calc vs. I ops plot which would show systematically under measured low angle 
reflections.

We also have a tool in development to bolt on to DIALS called screen19 which 
estimates the true peak photon rate from a “quick screening run” to offer 
insights into data collection options - https://github.com/xia2/screen19 - this 
is not perfect but you could find it useful. Our chemical crystallography users 
certainly find it helpful for planning their experiments.

Best wishes Graeme

On 4 Jun 2020, at 10:51, Alker, Andre M. 
<4599f25026c0-dmarc-requ...@jiscmail.ac.uk<mailto:4599f25026c0-dmarc-requ...@jiscmail.ac.uk>>
 wrote:

Dear Jiyuan,

maybe I can add something from the small molecule crystallographer view :-)

Crystallization:
For crystallization of small molecules you normally use solvents and water or 
mixtures as mentioned already before. At my lab the most successful way to 
crystallise is evaporation. Please use small glass vials (no plastic, some 
solvents will solute them too).

You can also use crystallization kits. Here you can use Bernhard Spinglers kit 
and or the Hampton kit. The Hampton kit didn't work so well for my molecules. I 
also bought Bernhard's kit but had no time to test it so far. I have to say I'm 
only using crystallization kits at the moment as last try. Maybe that changes 
in the future.

Measurement:
Of course you can use the synchrotron for small molecules at the protein 
beamline. I'm using the PXII protein beamline at the SLS (Swiss light source) 
for my small molecules if the crystals are too small for my inhouse system or 
there is a problem with my inhouse system. To get the resolution you need for 
structure solution and a good refinement you have to change the wavelength to 
0.7Å. Collect always at least 360 degrees  in steps of 0.5 degrees or smaller. 
Use high filters and short exposure times to secure your crystal against 
radiation damage. Normally 10 to 20% of the beam and 0.01 to 0.1 sec work fine 
depending on the crystal size. Do the measurement at low temperatures as usual 
for protein crystals. Here are my parameters for the SLS-PXII beamline equipped 
with an Eiger detector (wavelength 0.7Å, biggest aperture, 20% transmission, 
step 0.1 deg/0.01 sec, 1800 degrees, 100K).

Processing, structure solution and refinement:
I process the eiger data with XDS,
for structure solution I'm using shelxs or shelxd,
for structure refinement shelxl.

But as mentioned before there are a lot of programs doing processing, structure 
solution and refinement. I just started to use Olex as well for solution and 
refinement. In very earlier times I also used hkl2000 for data processing but 
in my opinion XDS is doing a very good job for small molecule data.

Last but not least I deeply agree with Navdeep to read Mueller et al.'s 
excellent book about Crystal Structure Refinement.

Hope this helps a little bit :-)

Best regards,
André






André Alker
Senior Scientist, pCMC Analytics
Roche Pharmaceutical Research and Early Development
Roche Innovation Center Basel
F. Hoffmann-La Roche Ltd
Grenzacherstrasse 124
4058 Basel, Switzerland
Phone: +41-61-6880935
email: andre_m.al...@roche.com<mailto:andre_m.al...@roche.com>

Upcoming absences:
...

Hinweis:
Der Inhalt dieser E-Mail kann vertrauliche Angaben enthalten, die nur für den 
(die) namentlich gena

Re: [ccp4bb] Question about small molecule crystallography

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear All,

A small word of caution regarding chemical crystallography on an MX-like 
beamline - if you have a bright source, a well diffracting crystal and a pixel 
array detector it is perfectly possible to lose counts in the strongest 
reflections without noticing - certainly without going over the nominal 
detector count limits if your mosaic spread is very small

At Diamond we faced this issue with i19, which is a dedicated chemical 
crystallography beamline on an undulator source, with a Pilatus 2 detector - it 
turns out to be very very easy to exceed the count rate where the detector 
electronics can keep up. This is somewhat less of a problem with Pilatus 3 and 
Eiger 2X detectors.

So: I would strongly suggest really turning down the intensity on the beam, use 
fine slicing and be prepared to check that the data are OK before removing your 
sample. You can solve and refine the structure with e.g. SHELX and get an F^2 
calc vs. I ops plot which would show systematically under measured low angle 
reflections.

We also have a tool in development to bolt on to DIALS called screen19 which 
estimates the true peak photon rate from a “quick screening run” to offer 
insights into data collection options - https://github.com/xia2/screen19 - this 
is not perfect but you could find it useful. Our chemical crystallography users 
certainly find it helpful for planning their experiments.

Best wishes Graeme

On 4 Jun 2020, at 10:51, Alker, Andre M. 
<4599f25026c0-dmarc-requ...@jiscmail.ac.uk>
 wrote:

Dear Jiyuan,

maybe I can add something from the small molecule crystallographer view :-)

Crystallization:
For crystallization of small molecules you normally use solvents and water or 
mixtures as mentioned already before. At my lab the most successful way to 
crystallise is evaporation. Please use small glass vials (no plastic, some 
solvents will solute them too).

You can also use crystallization kits. Here you can use Bernhard Spinglers kit 
and or the Hampton kit. The Hampton kit didn't work so well for my molecules. I 
also bought Bernhard's kit but had no time to test it so far. I have to say I'm 
only using crystallization kits at the moment as last try. Maybe that changes 
in the future.

Measurement:
Of course you can use the synchrotron for small molecules at the protein 
beamline. I'm using the PXII protein beamline at the SLS (Swiss light source) 
for my small molecules if the crystals are too small for my inhouse system or 
there is a problem with my inhouse system. To get the resolution you need for 
structure solution and a good refinement you have to change the wavelength to 
0.7Å. Collect always at least 360 degrees  in steps of 0.5 degrees or smaller. 
Use high filters and short exposure times to secure your crystal against 
radiation damage. Normally 10 to 20% of the beam and 0.01 to 0.1 sec work fine 
depending on the crystal size. Do the measurement at low temperatures as usual 
for protein crystals. Here are my parameters for the SLS-PXII beamline equipped 
with an Eiger detector (wavelength 0.7Å, biggest aperture, 20% transmission, 
step 0.1 deg/0.01 sec, 1800 degrees, 100K).

Processing, structure solution and refinement:
I process the eiger data with XDS,
for structure solution I'm using shelxs or shelxd,
for structure refinement shelxl.

But as mentioned before there are a lot of programs doing processing, structure 
solution and refinement. I just started to use Olex as well for solution and 
refinement. In very earlier times I also used hkl2000 for data processing but 
in my opinion XDS is doing a very good job for small molecule data.

Last but not least I deeply agree with Navdeep to read Mueller et al.'s 
excellent book about Crystal Structure Refinement.

Hope this helps a little bit :-)

Best regards,
André






André Alker
Senior Scientist, pCMC Analytics
Roche Pharmaceutical Research and Early Development
Roche Innovation Center Basel
F. Hoffmann-La Roche Ltd
Grenzacherstrasse 124
4058 Basel, Switzerland
Phone: +41-61-6880935
email: andre_m.al...@roche.com

Upcoming absences:
...

Hinweis:
Der Inhalt dieser E-Mail kann vertrauliche Angaben enthalten, die nur für den 
(die) namentlich genannten Empfänger bestimmt sind. Falls Sie nicht der 
Adressat dieser E-Mail sind, nehmen Sie Verbindung mit dem Absender auf und 
löschen Sie diese Mitteilung. Jede unbefugte Verwendung der in dieser 
Mitteilung enthaltenen Informationen ist untersagt.
This message is intended only for the use of the named recipient(s) and may 
contain confidential and/or privileged information. If you are not the intended 
recipient, please contact the sender and delete this message. Any unauthorized 
use of the information contained in this message is prohibited.


On Wed, Jun 3, 2020 at 7:40 PM Navdeep Sidhu 
mailto:sid...@gmail.com>> wrote:
Dear Jiyuan,

There was a similar question on the bulletin board some 6 years 

Re: [ccp4bb] DIALS error

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear Maria

Please could you send (off list) the 3_experiments,expt and 3_reflections.refl 
files? Happy to take a look. I expect it’s related to your experiment geometry 
(beam centre or similar)

Thanks Graeme

On 11 May 2020, at 14:22, Demou, Maria 
mailto:maria.demou...@ucl.ac.uk>> wrote:

Hello,
I am very new to DIALS, and I have been trying to index these images, however 
whatever parameters I put there is no suitable lattice. I used half the images 
as the rest I was told had radiation damage, but still there is no result.



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


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




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

Re: [ccp4bb] What refinement programs are fully Open Source?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear Tim,

While I agree that the papers describing XDS are excellent (and acknowledge 
precisely this every time I talk about DIALS!) I am certain that the actual 
implementation of XDS deviates significantly from the mathematical descriptions 
in the paper for the simple reason that writing data processing programs is 
hard and XDS is good.

I think the spirit behind the original question is that the opportunity exists 
to inspect every calculation which took you from your measured data to whatever 
the science result is - in the general case I would imagine the number of 
people who _do_ inspect is vanishingly small, but there are no fundamental 
limitations to this. Having things be open is however independent of them being 
good :-) - I would not conflate these ideas

I also recognise the distinction between free and open source highlighted in 
the thread - with xia2 and DIALS we have been fortunate to get funding from 
Diamond Light Source, CCP4, Lawrence Berkeley National Lab, the EU, NIH and 
Wellcome Trust (with enthusiastic letters of support from many who are on this 
list) which puts us in the position of being able to make the product free to 
all end users as well as making the source code available for inspection - 
someone needs to pay the bills, ultimately, so I want to thank the various 
funding agencies for this, as well as end users for citations and letters of 
support.

Best wishes Graeme

On 7 May 2020, at 21:32, Tim Gruene 
mailto:tim.gru...@univie.ac.at>> wrote:

Dear Pietro,

to add a bit to Ethan's warning, you might even consider XDS open
source: although the very source is not freely downloadable, it is so
well documented that one could rewrite the program just from its
documentation. At least, this is how the program SAINT started, as
far as I now.

Best regards,
Tim

On Thu, 7 May 2020 17:18:38 +
"Roversi, Pietro (Dr.)" mailto:pr...@leicester.ac.uk>> 
wrote:

Thank you Ethan for taking the the time to answer and explain.
Yes I am sure I have asked a vague and imprecise question.

Practically, I am going to point to xia2 for data processing:
https://www.ccp4.ac.uk/newsletters/newsletter48/articles/Xia2/manual.html

and hope it is "Open Source enough" - without too much scrutiny on
dependencies?

So, what about a refinement suite of programs that is "just as Open
Source" as xia2 is for data processing?

Unless this second message of mine is making my re-drafted question
worse than the original one .

with best wishes,

Pietro


Pietro Roversi

Lecturer (Teaching and Research) https://le.ac.uk/natural-sciences/

LISCB Wellcome Trust ISSF Fellow

https://le.ac.uk/liscb/research-groups/pietro-roversi


Leicester Institute of Structural and Chemical Biology
Department of Molecular and Cell Biology, University of Leicester
Henry Wellcome Building
Lancaster Road, Leicester, LE1 7HB
England, United Kingdom

Skype: roversipietro
Mobile phone  +44 (0) 7927952047
Tel. +44 (0)116 2297237




From: Ethan A Merritt 
Sent: 07 May 2020 18:08
To: Roversi, Pietro (Dr.) 
Cc: CCP4BB@jiscmail.ac.uk 
Subject: Re: [ccp4bb] What refinement programs are fully Open Source?

On Thursday, 7 May 2020 09:34:13 PDT Roversi, Pietro (Dr.) wrote:
Dear all,

we are in the editorial stages of a manuscript that I submitted to
Wellcome Open Research for publication.

The journal/editor ask us to list fully Open Source alternatives to
the pieces of software we used, for example for data processing and
refinement.

What refinement programs are fully Open Source?

There are recurring battles and philosophical fractures over what
exactly "open source" means, either in practice or aspirationally.
You would do well to provide a definition before asking people for
suggestions that meet your criteria.

At one point the Open Source Foundation (OSF) claimed to have the
authority to declare something was or was not "open source" and kept
lists of approved code, but their definition was in conflict with
guidelines from other places including funding agencies [*].  Also
the OSF itself seems to have largely disappeared from view, so maybe
that's a bad place to start.

There are at least two fracture lines in this battle.
The one created by people who feel a need to distinguish between
"free/libre code" and "open code",  and the one created by people
whose main concern is "documentation and claims are not enough;
I need to see the code actually used for the calculations reported in
this work".
Then there's the concern mostly of interest to corporate legal
departments "can we use this in our commercial products".

   Ethan (coding veteran with scars from this battle)


[*] it was also in conflict with the ordinary English language meaning
of "open" and "source", which didn't help any.



Thanks!

Pietro


Pietro Roversi

Lecturer (Teaching and Research) https://le.ac.uk/natural-sciences/

LISCB Wellcome Trust ISSF Fellow

Re: [ccp4bb] What refinement programs are fully Open Source?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Pietro,

To be precise, xia2 is a tool (which is open source under any definition - BSD 
licensed) for running data processing programs on your behalf. If you run with 
DIALS for indexing, integration and scaling (which are licensed the same way, 
and uses cctbx which is also open source) then it is true that you have run 
essentially a full stack of open source to get you from images to scaled and 
merged intensities

All of this is available on GitHub

All the best Graeme

On 7 May 2020, at 18:18, Roversi, Pietro (Dr.) 
mailto:pr...@leicester.ac.uk>> wrote:

Thank you Ethan for taking the the time to answer and explain.
Yes I am sure I have asked a vague and imprecise question.

Practically, I am going to point to xia2 for data processing:
https://www.ccp4.ac.uk/newsletters/newsletter48/articles/Xia2/manual.html

and hope it is "Open Source enough" - without too much scrutiny on dependencies?

So, what about a refinement suite of programs that is "just as Open Source" as 
xia2 is for data processing?

Unless this second message of mine is making my re-drafted question worse than 
the original one .

with best wishes,

Pietro

Pietro Roversi
Lecturer (Teaching and Research) https://le.ac.uk/natural-sciences/
LISCB Wellcome Trust ISSF Fellow
https://le.ac.uk/liscb/research-groups/pietro-roversi


Leicester Institute of Structural and Chemical Biology
Department of Molecular and Cell Biology, University of Leicester
Henry Wellcome Building
Lancaster Road, Leicester, LE1 7HB
England, United Kingdom

Skype: roversipietro
Mobile phone  +44 (0) 7927952047
Tel. +44 (0)116 2297237




From: Ethan A Merritt mailto:merr...@uw.edu>>
Sent: 07 May 2020 18:08
To: Roversi, Pietro (Dr.) mailto:pr...@leicester.ac.uk>>
Cc: CCP4BB@jiscmail.ac.uk 
mailto:CCP4BB@jiscmail.ac.uk>>
Subject: Re: [ccp4bb] What refinement programs are fully Open Source?

On Thursday, 7 May 2020 09:34:13 PDT Roversi, Pietro (Dr.) wrote:
> Dear all,
>
> we are in the editorial stages of a manuscript that I submitted to Wellcome 
> Open Research for publication.
>
> The journal/editor ask us to list fully Open Source alternatives to the 
> pieces of software we used, for example for data processing and refinement.
>
> What refinement programs are fully Open Source?

There are recurring battles and philosophical fractures over what exactly
"open source" means, either in practice or aspirationally.
You would do well to provide a definition before asking people for
suggestions that meet your criteria.

At one point the Open Source Foundation (OSF) claimed to have the authority
to declare something was or was not "open source" and kept lists of
approved code, but their definition was in conflict with guidelines from
other places including funding agencies [*].  Also the OSF itself seems to
have largely disappeared from view, so maybe that's a bad place to start.

There are at least two fracture lines in this battle.
The one created by people who feel a need to distinguish between
"free/libre code" and "open code",  and the one created by people
whose main concern is "documentation and claims are not enough;
I need to see the code actually used for the calculations reported in
this work".
Then there's the concern mostly of interest to corporate legal
departments "can we use this in our commercial products".

Ethan (coding veteran with scars from this battle)


[*] it was also in conflict with the ordinary English language meaning
of "open" and "source", which didn't help any.


>
> Thanks!
>
> Pietro
>
>
> Pietro Roversi
>
> Lecturer (Teaching and Research) https://le.ac.uk/natural-sciences/
>
> LISCB Wellcome Trust ISSF Fellow
>
> https://le.ac.uk/liscb/research-groups/pietro-roversi
>
>
> Leicester Institute of Structural and Chemical Biology
> Department of Molecular and Cell Biology, University of Leicester
> Henry Wellcome Building
> Lancaster Road, Leicester, LE1 7HB
> England, United Kingdom
>
> Skype: roversipietro
> Mobile phone  +44 (0) 7927952047
> Tel. +44 (0)116 2297237
>
>
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2Fwebadmin%3FSUBED1%3DCCP4BB%26A%3D1data=02%7C01%7Cpr159%40leicester.ac.uk%7Cf8cc2fb23bb84707d7a708d7f2a96338%7Caebecd6a31d44b0195ce8274afe853d9%7C0%7C0%7C637244681673138009sdata=nfhtEWy2FS96MYwaHsT4qoQi%2BMbPetQdTwfAf3FDjGg%3Dreserved=0
>


--
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, 

Re: [ccp4bb] Raw diffraction images for SARS-CoV-2 related structures

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear all,

John - I sent off list a PDB / DOI map over the weekend

Some rough edges have now been polished however the code is currently not 
_really_ fit for publication. That said, if any other facilities would like to 
get in touch for information about how to do this please do - I would hate to 
see people reinventing the wheel.

Right now I have tools for

 - creating uploads from a collection of files & some metadata
 - updating published records e.g. changing keywords or … fixing typos
 - searching zenodo programmatically e.g. to generate the DOI / PDB reference 
above

So if anyone is interested please drop me a line off list

All the best Graeme

On 28 Mar 2020, at 06:12, Winter, Graeme (DLSLtd,RAL,LSCI) 
mailto:graeme.win...@diamond.ac.uk>> wrote:

Hi John,

Sure, happy to do this, just as soon as I figure how to do this automatically 
;-)

Thank you Gerard for your kind words - as people will note there are a couple 
of rough edges at the moment (as illustrated with typos) - however once these 
are tidied up I’ll circulate the location of the code and dependencies for the 
upload so other facilities can follow suit.

If people find any issues with the uploads then please get in touch (off list)

Best wishes Graeme




On 27 Mar 2020, at 19:56, John Berrisford 
mailto:j...@ebi.ac.uk>> wrote:

HI

This is great news.

Can you let us at the PDB know the DOI's for each dataset so that we can 
associate the raw images with the PDB entry.  We will be able to then show 
links to the raw images from PDB entry pages so that everyone can find them.

Many thanks

John


John Berrisford
PDBe
+44 1223 492529
European Bioinformatics Institute (EMBL-EBI) European Molecular Biology 
Laboratory Wellcome Trust Genome Campus Hinxton Cambridge CB10 1SD 
UK<https://maps.google.com/?q=European%20Bioinformatics%20Institute%20(EMBL-EBI)%20European%20Molecular%20Biology%20Laboratory%20Wellcome%20Trust%20Genome%20Campus%20Hinxton%20Cambridge%20CB10%201SD%20UK>
https://www.pdbe.org<https://www.pdbe.org/>
[Facebook]<http://www.facebook.com/proteindatabank>[Twitter]<https://twitter.com/PDBeurope>
On Mar 27 2020, at 7:26 pm, Gerard Bricogne 
mailto:g...@globalphasing.com>> wrote:
Dear all, It is a pleasure to be able to end the (GMT) week by calling for a 
huge round of applause for the Diamond team, who this afternoon started 
uploading a large collection of sets of raw diffraction images (77 as we write 
but the upload is still ongoing) for PDB entries that were released two days 
ago. Special thanks to Graeme Winter who organised the upload to Zenodo. The 
datasets are collectively accessible via the following link: 
https://zenodo.org/search?page=1=20=keywords:%22SARS-CoV-2%20main%20protease%22
 Graeme asked that "major kudos [be given] to Zenodo developers who have been 
very responsive with helping us do automated downloads". Happy scrutiny and 
reprocessing of these datasets, and re-refinement of the associated structures, 
to all hard-core MX addicts! With best wishes, Clemens & Gerard. -- On Thu, Mar 
19, 2020 at 10:00:11AM +, John Berrisford wrote: > Dear all > > The wwPDB 
OneDep system allows depositors to provide DOIs of raw > diffraction images 
during deposition to the PDB and once again > encourages depositors to provide 
a DOI for raw images when they have > submitted. > > Out of the 9665 X-ray 
entries that were released in 2019 we have DOI's > for raw images in 205 of 
these entries. > > We would encourage depositors to provide the DOI for their 
raw images > when they are available. > > Regards > > John > > > On Mar 19 
2020, at 9:48 am, Joel Sussman wrote: > > > 19-Mar-2020 > > Dear Loes, Peter, 
Clemens & Gerard, > > I concur that it is crucial to preserve the original 
diffraction data > > and make it available to anyone who would like to use it. 
> > As an example, please see the very recent paper by  > > Nachon et al 
(2020). "A second look at the crystal structures of > > Drosophila melanogaster 
acetylcholinesterase in complex with tacrine > > derivatives provides Insights 
concerning catalytic intermediates and > > the design of specific insecticides" 
Molecules 25 pii: E1198  > > [https://www.ncbi.nlm.nih.gov/pubmed/32155891]. > 
> The study reexamines the original data, with modern software tools, > > the 
original data of a paper we published in 2000 (~20 years ago) and > > revealed 
features that had not been noticed. Specifically  > > 1) previously unmodeled 
density in the native active site can be > > interpreted as stable acetylation 
of the catalytic serine.  > > 2) Similarly, a strong density in the DmAChE/ZA 
complex, originally > > attributed to a sulfate ion, is better interpreted as a 
small molecule > > that is covalently bound. T

Re: [ccp4bb] Raw diffraction images for SARS-CoV-2 related structures

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi John,

Sure, happy to do this, just as soon as I figure how to do this automatically 
;-)

Thank you Gerard for your kind words - as people will note there are a couple 
of rough edges at the moment (as illustrated with typos) - however once these 
are tidied up I’ll circulate the location of the code and dependencies for the 
upload so other facilities can follow suit.

If people find any issues with the uploads then please get in touch (off list)

Best wishes Graeme




On 27 Mar 2020, at 19:56, John Berrisford 
mailto:j...@ebi.ac.uk>> wrote:

HI

This is great news.

Can you let us at the PDB know the DOI's for each dataset so that we can 
associate the raw images with the PDB entry.  We will be able to then show 
links to the raw images from PDB entry pages so that everyone can find them.

Many thanks

John


John Berrisford
PDBe
+44 1223 492529
European Bioinformatics Institute (EMBL-EBI) European Molecular Biology 
Laboratory Wellcome Trust Genome Campus Hinxton Cambridge CB10 1SD 
UK
https://www.pdbe.org
[Facebook][Twitter]
On Mar 27 2020, at 7:26 pm, Gerard Bricogne 
mailto:g...@globalphasing.com>> wrote:
Dear all, It is a pleasure to be able to end the (GMT) week by calling for a 
huge round of applause for the Diamond team, who this afternoon started 
uploading a large collection of sets of raw diffraction images (77 as we write 
but the upload is still ongoing) for PDB entries that were released two days 
ago. Special thanks to Graeme Winter who organised the upload to Zenodo. The 
datasets are collectively accessible via the following link: 
https://zenodo.org/search?page=1=20=keywords:%22SARS-CoV-2%20main%20protease%22
 Graeme asked that "major kudos [be given] to Zenodo developers who have been 
very responsive with helping us do automated downloads". Happy scrutiny and 
reprocessing of these datasets, and re-refinement of the associated structures, 
to all hard-core MX addicts! With best wishes, Clemens & Gerard. -- On Thu, Mar 
19, 2020 at 10:00:11AM +, John Berrisford wrote: > Dear all > > The wwPDB 
OneDep system allows depositors to provide DOIs of raw > diffraction images 
during deposition to the PDB and once again > encourages depositors to provide 
a DOI for raw images when they have > submitted. > > Out of the 9665 X-ray 
entries that were released in 2019 we have DOI's > for raw images in 205 of 
these entries. > > We would encourage depositors to provide the DOI for their 
raw images > when they are available. > > Regards > > John > > > On Mar 19 
2020, at 9:48 am, Joel Sussman wrote: > > > 19-Mar-2020 > > Dear Loes, Peter, 
Clemens & Gerard, > > I concur that it is crucial to preserve the original 
diffraction data > > and make it available to anyone who would like to use it. 
> > As an example, please see the very recent paper by  > > Nachon et al 
(2020). "A second look at the crystal structures of > > Drosophila melanogaster 
acetylcholinesterase in complex with tacrine > > derivatives provides Insights 
concerning catalytic intermediates and > > the design of specific insecticides" 
Molecules 25 pii: E1198  > > [https://www.ncbi.nlm.nih.gov/pubmed/32155891]. > 
> The study reexamines the original data, with modern software tools, > > the 
original data of a paper we published in 2000 (~20 years ago) and > > revealed 
features that had not been noticed. Specifically  > > 1) previously unmodeled 
density in the native active site can be > > interpreted as stable acetylation 
of the catalytic serine.  > > 2) Similarly, a strong density in the DmAChE/ZA 
complex, originally > > attributed to a sulfate ion, is better interpreted as a 
small molecule > > that is covalently bound. The complex is reminiscent of the 
> > carboxylate/BChE complexes observed in crystal structures of hBChE > > 
[Brazzolotto et al, 2012; Nicolet et al, 2003], and demonstrates the > > 
remarkable ability of ChEs to stabilize covalent complexes with carboxylates. > 
> Thus, the study demonstrates that updated processing of older > > diffraction 
images, and the re-refinement of older diffraction data, > > can produce 
valuable information that could not be detected in the > > original analysis, 
and strongly supports the preservation of the > > diffraction images in public 
data banks. > > Best regards > > Joel > > 

 > > Prof. Joel L. Sussman.
joel.suss...@weizmann.ac.il   
www.weizmann.ac.il/~joel > > Dept. of 
Structural Biology   tel: +972  (8) 934 6309   
proteopedia.org > > Weizmann Institute of Science fax: 
+972  

Re: [ccp4bb] Raw diffraction images for SARS-CoV-2 related structures

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Folks,

Quick note on "Like a super raw image diet-plan for the incoming summer” - the 
bslz4 compression used with Eiger works really well, and the data are pretty 
close to entropy limit in terms of size - which means if you measure your data 
carefully (i.e. low background etc.) you can realistically have a full Eiger 
data set which will fit on a DVD -

Grey-Area i04-ins :) $ du -ach insu_d200_1*h5
2.5Ginsu_d200_1_01.h5
1.9Ginsu_d200_1_02.h5
 92Kinsu_d200_1_master.h5
138Minsu_d200_1_meta.h5
4.0Kinsu_d200_1_meta_pack.h5
4.5Gtotal

which I think is pretty modest storage wise - this is 1,800 image Eiger 16M 
data set so pretty realistic. 

No matter how much data we produce, the particle physicists have us beat, and I 
would wager that netflix is a couple of orders of magnitude worse than MX for 
the environment. 

Also, it costs a lot more CO2 to produce the data than to store it - 
synchrotrons don’t run on wind turbines ;-)  

I agree with Clemens - if we are serious about revisiting the data, you have to 
have access to the actual data rather than a description of the data (which is 
essentially what an MTZ file is) 

A small administrative note for those uploading to zenodo etc - 

if you are uploading HDF5 as above, this works fine
if you are uploading CBF images, would suggest you gzip / bzip2 compress them 
(pick one) and then tar up each sweep independently before upload

 - makes fetching the data back down again efficient. Zenodo does not do well 
with many many small files (I have discussed this with the zenodo developers - 
it is a reasonable design choice) 

Finally I would ask if you do upload raw data please also upload the beamline 
parameters you used e.g. the beam centre from a white board or whatever - if 
it’s not in the headers it is not known 

All the best Graeme

> On 19 Mar 2020, at 08:47, Julien Cappèle  
> wrote:
> 
> Hi everyone,
> 
> There are some very interesting ideas. 
> 
> Though I agree with you Clement that raw images are amazing to work with as 
> you can use any software you are confortable with, we cannot forget that 
> depositing several TB of data for each lab would be bad for ecological 
> reason. And because detectors are always improving (thank you all!), size of 
> data will increase exponentially. 
> 
> Correct me if I'm wrong, as I am not that familiar with the way that 
> integration of raw images works:
> 
> Could it be possible for a new/already existing software to store reflections 
> (area, intensity from center to border, position x/y on the image, and 
> information of the image) in a lightweight and text only file ? Possibly a 
> new format to be used for integration ?
> 
> While those text files would be heavy, they'd be still lighter than raw 
> images and the whole useless white space they carry with them between 
> reflections.
> 
> If not possible, could we imagine to eliminate all the unused space on these 
> ? Like a super raw image diet-plan for the incoming summer !
> 
> Best regards,
> 
> Julien CAPPELE
> Université de Lorraine, Nancy, France
> PhD student - 2nd Year
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1


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




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

Re: [ccp4bb] What resolution - X-ray diffraction round this time

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hi Dusan,

I am pretty sure

"It is well accepted that the criteria for resolution cutoff should consider 
both I/SigI and Rmerge for the outer most shell. For data sets collected at 
synchrotron sources, the criteria of I/SigI > 5 and Rmerge <50% can be taken as 
a good practical reference.”

has been considered obsolete for a number of years - the efforts of many have 
shown that this is not good practice, including but not limited to Karplus & 
Diederichs - https://science.sciencemag.org/content/336/6084/1030.long

The suggestion above is to throw away large amounts of almost certainly useful 
information, which cannot give rise to a better model

Best wishes Graeme

On 28 Feb 2020, at 08:22, dusan turk 
mailto:dusan.t...@ijs.si>> wrote:

Hi,

Browsing through the recent discussion on EM data resolution cutoff it occurred 
to me that the X-ray diffraction community isn’t that unanimous either.

My stand:

When the default resolution cutoff provided with the data processing software 
in electron density map calculation and refinement delivers quality maps 
noisier than expected and/or too high R-factors I start adjusting the 
resolution cutoff by lowering the resolution and trying alternative space 
group.   Hence, I allow the data processing programs to suggest where to draw 
the line (be it CC1/2, I/sigI, R merge, R sym, R p.i.m. and R r.i.m, …) , 
unless there are problems.

Doing so, I came into a dispute with a referee who shaped his request:

"It is well accepted that the criteria for resolution cutoff should consider 
both I/SigI and Rmerge for the outer most shell. For data sets collected at 
synchrotron sources, the criteria of I/SigI > 5 and Rmerge <50% can be taken as 
a good practical reference.”

So where do we stand? Which are the most objective criteria for resolution 
cutoff to be used in diffraction data processing? Which number of shells to use 
when calculating the statistics? Do we have a consensus?

best wishes,

dusan turk



Dr. Dusan Turk, Prof.
Head of Structural Biology Group http://stef.ijs.si/
Head of Centre for Protein  and Structure Production
Centre of excellence for Integrated Approaches in Chemistry and Biology of 
Proteins, Scientific Director
http://www.cipkebip.org/
e-mail: dusan.t...@ijs.si
phone: +386 1 477 3857   Dept. of Biochem.& Mol.& Struct. Biology
fax:  +386 1 477 3984   Jozef Stefan Institute
   Jamova 39, 1 000 Ljubljana,Slovenia
Skype: dusan.turk (voice over internet: www.skype.com



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


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




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

Re: [ccp4bb] MX data processing with GPUs??

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Folks,

To clarify following a couple of questions re: sizes of Eiger data sets

Sparsely measured Eiger data compress very well indeed - I have seen cases 
where the compressed data are around 100 kB / frame for 18 megapixels

The issue I was addressing below is that the pixels stored in RAM are typically 
worked with as 32 bit integers, even if the underlying acquisition was using 16 
bit. Thus the bytes which have to be worked on by the CPU are massively larger 
than the data on disk… even if most of the bits are 0’s :-)

Best wishes Graeme



On 19 Feb 2020, at 08:08, Winter, Graeme (DLSLtd,RAL,LSCI) 
mailto:graeme.win...@diamond.ac.uk>> wrote:

Dear Ana,

To follow up on the contributions from others, there are some particular 
annoyances with MX processing which differentiate it from other “big data” or 
imaging problems.

In tomographic reconstruction you have a big block of data which needs to (as a 
simplistic approximation) be transformed by a bunch of trigonometric functions 
to another big block of data. The shape of the calculation is the same 
independent of the data itself, and overall this represents a massively 
parallel computationally expensive problem, which makes it worth the cost of 
getting the data in and out of the GPU (this is not cheap) - even in this case, 
the parallelism of modern CPUs means that this is not a given. These folks are 
usually the ones who are making a lot of noise about how awesome GPU boards 
are, and for their use case this is absolutely true.

In MX we have a particularly annoying problem, as about half of the 
calculations are nicely parallel (spot finding, peak integration) and are 
memory bandwidth / CPU breadth limited and the other half (indexing, 
refinement, scaling) are not very parallel CPU speed bound, so finding the best 
CPU architecture is hard to start with. In terms of GPU, the data need to 
typically pass through main memory three times - for spot finding you need to 
look at every pixel, and integration typically needs to load full frames to 
extract the profiles and then fit them (the shoebox regions can be cached 
between these, but they still need to pass in and out of the CPU). Since moving 
data in and out of memory is expensive and GPU memory is expensive this is a 
problem. For reference, a typical Eiger 16M data set uncompressed needs about 
half a terabyte of RAM (7,200 * 18 megapixels * 4 bytes) so in memory 
processing presents real challenges. The image analysis calculations themselves 
are typically rather light weight floating point work (e.g. summed area table 
calculations) without a lot of trigonometry.

All this, combined with the annoying habit of using words like “if” and “for” 
in the code (which kills GPU calculations dead) mean that even for spot finding 
it’s not worth the effort of moving the data into a GPU - we DIALS folks looked 
into this a couple of years back with a specialist from NVIDIA.

For what it’s worth we have spent some time looking at this here at Diamond, 
where we have a certain interest in speedy processing of MX data and the 
current (2020/02) best bang for buck appears to be AMD Rome.

We as a community have a challenge with keeping up with high data rate 
beamlines at both synchrotrons and FELs - I feel it is important to keep an eye 
on emerging technology and make best use of it (and share experiences of using 
it!) but we should also keep in mind that the processing done in MX is actually 
rather well defined and mathematical at its heart. It is very unlikely that 
deep learning will help with the mathematical challenges we face [1] as we know 
exactly the calculations we need to do (which are very well documented in the 
literature, thank you to everyone who has written these up over the years) and 
instead a clear focus on making the maths fast is needed.

Up to the point where someone comes up with a completely new way of looking at 
the data, of course. I’m sure someone out there is looking at this :-)

On the topic of raspberry pi machines ;-) these are fun but I would hate to 
look at the interconnect necessary to get enough boards to work together to 
keep up with a single AMD Rome box…

best wishes Graeme

[1] with the possible exception of classifying individual found spots and other 
niche areas


On 19 Feb 2020, at 07:04, Leonarski Filip Karol (PSI) 
mailto:filip.leonar...@psi.ch>> wrote:

Dear Ana,

To benefit from GPU architecture, over CPU, the algorithm needs to do quite 
significant number crunching – i.e. do at least certain number of floating 
point operations (FLOP) per one byte of data. It also needs to be highly 
parallel, preferably without conditional (if/else) statements. Finally, there 
is a variety of GPU architectures on the market and it is not exactly obvious 
that code written for one GPU will be optimal on another one. So if the code is 
based on a general purpose library, it will be easier to make sure that it runs 
efficiently on all GPU hardware

Re: [ccp4bb] MX data processing with GPUs??

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear Ana,

To follow up on the contributions from others, there are some particular 
annoyances with MX processing which differentiate it from other “big data” or 
imaging problems.

In tomographic reconstruction you have a big block of data which needs to (as a 
simplistic approximation) be transformed by a bunch of trigonometric functions 
to another big block of data. The shape of the calculation is the same 
independent of the data itself, and overall this represents a massively 
parallel computationally expensive problem, which makes it worth the cost of 
getting the data in and out of the GPU (this is not cheap) - even in this case, 
the parallelism of modern CPUs means that this is not a given. These folks are 
usually the ones who are making a lot of noise about how awesome GPU boards 
are, and for their use case this is absolutely true.

In MX we have a particularly annoying problem, as about half of the 
calculations are nicely parallel (spot finding, peak integration) and are 
memory bandwidth / CPU breadth limited and the other half (indexing, 
refinement, scaling) are not very parallel CPU speed bound, so finding the best 
CPU architecture is hard to start with. In terms of GPU, the data need to 
typically pass through main memory three times - for spot finding you need to 
look at every pixel, and integration typically needs to load full frames to 
extract the profiles and then fit them (the shoebox regions can be cached 
between these, but they still need to pass in and out of the CPU). Since moving 
data in and out of memory is expensive and GPU memory is expensive this is a 
problem. For reference, a typical Eiger 16M data set uncompressed needs about 
half a terabyte of RAM (7,200 * 18 megapixels * 4 bytes) so in memory 
processing presents real challenges. The image analysis calculations themselves 
are typically rather light weight floating point work (e.g. summed area table 
calculations) without a lot of trigonometry.

All this, combined with the annoying habit of using words like “if” and “for” 
in the code (which kills GPU calculations dead) mean that even for spot finding 
it’s not worth the effort of moving the data into a GPU - we DIALS folks looked 
into this a couple of years back with a specialist from NVIDIA.

For what it’s worth we have spent some time looking at this here at Diamond, 
where we have a certain interest in speedy processing of MX data and the 
current (2020/02) best bang for buck appears to be AMD Rome.

We as a community have a challenge with keeping up with high data rate 
beamlines at both synchrotrons and FELs - I feel it is important to keep an eye 
on emerging technology and make best use of it (and share experiences of using 
it!) but we should also keep in mind that the processing done in MX is actually 
rather well defined and mathematical at its heart. It is very unlikely that 
deep learning will help with the mathematical challenges we face [1] as we know 
exactly the calculations we need to do (which are very well documented in the 
literature, thank you to everyone who has written these up over the years) and 
instead a clear focus on making the maths fast is needed.

Up to the point where someone comes up with a completely new way of looking at 
the data, of course. I’m sure someone out there is looking at this :-)

On the topic of raspberry pi machines ;-) these are fun but I would hate to 
look at the interconnect necessary to get enough boards to work together to 
keep up with a single AMD Rome box…

best wishes Graeme

[1] with the possible exception of classifying individual found spots and other 
niche areas


On 19 Feb 2020, at 07:04, Leonarski Filip Karol (PSI) 
mailto:filip.leonar...@psi.ch>> wrote:

Dear Ana,

To benefit from GPU architecture, over CPU, the algorithm needs to do quite 
significant number crunching – i.e. do at least certain number of floating 
point operations (FLOP) per one byte of data. It also needs to be highly 
parallel, preferably without conditional (if/else) statements. Finally, there 
is a variety of GPU architectures on the market and it is not exactly obvious 
that code written for one GPU will be optimal on another one. So if the code is 
based on a general purpose library, it will be easier to make sure that it runs 
efficiently on all GPU hardware.

I believe combination of these factors makes a big difference between imaging 
and MX.

Imaging processing is limited by FFT performance, which needs floating point 
performance. Libraries for FFT on GPUs are standard and provided by hardware 
vendors, so it is easy to implement.

On the other hand MX algorithms for image processing, at least the one I know 
of, do only handful of FLOP per pixel and they will probably not benefit from 
GPU processing significantly, even if ported to such architecture – which would 
be also a non-negligible effort. So while it is not impossible to imagine 
GPU-accelerated MX software and hopefully people are working on this, it 

Re: [ccp4bb] data processing

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear Smita,

You need only do a format conversion I expect, no processing required. For this 
you will want either f2mtz -

http://www.ccp4.ac.uk/html/f2mtz.html

or pointless - here use the -c option to copy rather than performing the 
analysis on the data

http://www.ccp4.ac.uk/html/pointless.html

For the latter I would guess you are looking at SAINT format for Bruker, 
detailed at

http://www.ccp4.ac.uk/html/pointless.html#input_and_output_files

Best wishes Graeme

On 14 Feb 2020, at 04:22, smita yadav 
mailto:sm...@rcb.res.in>> wrote:

Dear community,
  I collected the data in bruker d8 venture for 
protein crystal. I process the data in proteum3. it generated the hkl file. how 
can i use the further processing of it to get mtz file. and what parameters 
needs to consider or check, wheather it is correct or not.



--
Regards,
Smita Yadav
Ph.D JRF
Regional Centre for biotechnology,
Haryana-121001.



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


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




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

Re: [ccp4bb] Representation within tutors at workshops

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear Selina, All,

Apropos:


For one, there are expert users for the software taught at these courses. 
Often, the software developers
know these persons, and it would be great if they could nominate at least one 
or two persons who could
teach in their place, having gender balance and (age) diversity in mind.

I would say that in many respects an expert user is a better tutor than a 
developer on many occasions, in addition to any benefits to diversity - they 
are more likely to be able to see things from the user’s perspective (in my 
opinion, as a developer)

 * however *

The tutoring is not the only reason developers go on the workshops

Sometimes it is necessary to debug / fix things in situ, sometimes weird things 
happen which only the developer can explain and also - I feel strongly - that 
developers _should_ interact directly with users both expert and novice 
otherwise we will never get feedback about the software and make improvements. 
Without seeing how people use the software - and how experts recommend using it 
- we will never learn ourselves! It also gives a chance to improve the 
knowledge of the expert users, since they themselves may be out of date

So - sadly for the environment and funding agencies - I can see excellent 
arguments for *both* expert users and developers to be attending the workshops 
- which would also provide opportunities for early career scientists - from any 
group - to get teaching experience as well as helping to train a cadre of 
expert users to help with workshops.

Best wishes 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




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

[ccp4bb] Representation within tutors at workshops

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear all,

This is an interesting debate on a complex topic, which firstly I would like to 
slightly disentangle from the workshop itself - hence the subject change. I do 
this as some of the comments could be interpreted as directed specifically at 
the workshop organisers, which I do not feel is appropriate here without 
knowledge of the full facts.

Speaking as someone who helps to arrange these workshops as well as 
contributing to some, the “load” on speakers is high - this year CCP4 are 
contributing to and running around 8 workshops - each of these last about a 
week, and typically involve a dozen or so tutors. They are typically 
oversubscribed, and are geographically spread for the benefit of the students - 
however this geographic spread is not represented in the speakers, so it is 
sometimes hard to get tutors to travel.

Regarding awareness of gender balances, I would say that this is close to the 
minds of everyone who I have talked to about organising workshops, and without 
making any judgements about the correctness or otherwise of positive bias, 
coming up with a balanced list of speakers - according to any metric - is hard. 
Doing this within budget, and within the capabilities of the speakers 
themselves who are (as was pointed out earlier) typically doing this for 
altruistic reasons only makes this harder. In my experience though this does 
not stop people from trying, and I am sure we will all continue to try.

A final comment though is we should be aiming for inclusivity and equality 
within the community and bb - across age, experience, gender, background etc - 
and I do take offence to the idea that reading a specific book is considered a 
precondition for commenting on a topic. I would certainly endorse a proposal 
that “this topic has been discussed well in this book” as a suggestion. 
Teaching people is ultimately what this thread is all about!

Humbly written as a middle aged white guy :-)

All the best,

Graeme

On 6 Feb 2020, at 01:19, Susan Lea 
mailto:susan@path.ox.ac.uk>> wrote:

Perhaps some of the respondents to this question should real Angela Saini’s 
Inferior before commenting in public
Susan

Sent from my iPhone

On 5 Feb 2020, at 19:18, Robert Nicholls 
mailto:nicho...@mrc-lmb.cam.ac.uk>> wrote:


As a Caucasian male I hesitate to post; I know that there are a lot of people 
who are sensitive to this subject, so feel that I'm treading on eggshells in 
responding... Nevertheless I feel obliged to respond, having a certain amount 
of insight into the topic in the context of these workshops.

Personally I don't find posts such as this - which simply incite (positive) 
discrimination - to be very constructive.

From speaking to organisers and being involved in committees over numerous 
years I know that gender bias is always very much at the forefront of the 
organisers' minds when deciding whom to invite. Especially where funding 
requirements and committees are involved, the issue of gender bias is always 
raised with a heavy hand. Consequently, in modern times whenever there is a 
gender bias in our field it is not a result of naivety or discriminative 
cliqueness, but rather necessity due to the availability of appropriate tutors 
(as correctly indicated by Rasmus). And as Andrew points out, organising these 
workshops takes a lot of effort, and as such it is inappropriate to treat the 
organisers with undue disrespect.

Ultimately, the objective is to teach the topics intended to be covered in the 
workshop. For sure, there are a number of very good females who are appropriate 
for teaching on these courses, despite being in the relative minority. I know a 
number of the females who are very able to tutor on such courses, and by 
personal communication I also know why some of them might not be able to attend 
this particular one this year. As Eleanor has pointed out, sometimes life gets 
in the way.

There is a very good gender balance of participants in these workshops, as is 
indicative of the demographic of practicing structural biologists wishing to 
utilise these software tools. But clearly the gender balance of tutors is 
heavily in favour of males - this represents the difference in gender ratios of 
people engaging with practical structural biology versus computational methods 
development.

I understand the argument that it is good for female tutors to be present as 
role models in such workshops, but it is worth noting that the people attending 
these workshops do not intend to become methods developers - they simply want 
to know how to best use the tools available. Consequently there is a 
qualitative difference between tutors and participants. Therefore, there is 
limited capability for the participants to see the tutors as role models in 
this context.

I feel that the junior vs senior argument isn't at all relevant. More senior 
developers will of course be generally preferred - it is necessary for 
individuals with sufficient experience to be 

Re: [ccp4bb] scaled but unmerged mtz from DIALS as input to staraniso

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Hello Eleanor

Is that the sound of worms escaping a pot I hear in the distance? Certainly is!

Yes, this is something which was raised with a few of my colleagues at the 
study weekend and something we are discussing internally - with my facility hat 
on I think we should get to the bottom of this one - early in the year.

best wishes Graeme

On 14 Jan 2020, at 11:03, Eleanor Dodson 
mailto:eleanor.dod...@york.ac.uk>> wrote:

Not quite relevent but is there some way of stamping these files with a record 
of where they were generated ?
I used to use my ability to read - name them myself as
SAMPLEX-dialsprocessing-unmerged.mtz then
SAMPLEX-dialsprocessing-unmerged-staranisod.mtz

and there is an mtz feature which wrote a history with dates as well but now 
with automated file naming it is hard to keep track of how a file was generated.


It seems likely that lots of Table !s do not describe the data set that was 
actually used for structure solution and deposition!

Eleanor

On Tue, 14 Jan 2020 at 10:11, Winter, Graeme (DLSLtd,RAL,LSCI) 
mailto:graeme.win...@diamond.ac.uk>> wrote:
Dear  Dave, Star Aniso Developers,

If this turns out to be because we are “missing something” i.e. there is an 
expectation on a property being present in the output files but it’s not there 
in our MTZ output, please let us know :-)

Best wishes Graeme

On 14 Jan 2020, at 09:06, David Lawson (JIC) 
mailto:david.law...@jic.ac.uk>> wrote:

Dear ccp4bb

I am trying to get the staraniso server to accept a scaled but unmerged mtz 
file from DIALS processing, but it reports an “Internal Server Error” after 
thinking about it for a while. Should this be possible? The file is 31 MB, so 
not huge.

It works fine for a merged mtz from DIALS, but this is not the preferred option 
and I don’t get the full statistics I need for Table 1.

Thanks in advance

Dave Lawson

---

Prof. David M. Lawson
Department of Biological Chemistry,
John Innes Centre,
Norwich,
NR4 7UH, UK.
Tel: +44-(0)1603-450725
Web: https://www.jic.ac.uk/people/david-lawson
Email: david.law...@jic.ac.uk<mailto:david.law...@jic.ac.uk>




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



--

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




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] scaled but unmerged mtz from DIALS as input to staraniso

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear  Dave, Star Aniso Developers,

If this turns out to be because we are “missing something” i.e. there is an 
expectation on a property being present in the output files but it’s not there 
in our MTZ output, please let us know :-)

Best wishes Graeme

On 14 Jan 2020, at 09:06, David Lawson (JIC) 
mailto:david.law...@jic.ac.uk>> wrote:

Dear ccp4bb

I am trying to get the staraniso server to accept a scaled but unmerged mtz 
file from DIALS processing, but it reports an “Internal Server Error” after 
thinking about it for a while. Should this be possible? The file is 31 MB, so 
not huge.

It works fine for a merged mtz from DIALS, but this is not the preferred option 
and I don’t get the full statistics I need for Table 1.

Thanks in advance

Dave Lawson

---

Prof. David M. Lawson
Department of Biological Chemistry,
John Innes Centre,
Norwich,
NR4 7UH, UK.
Tel: +44-(0)1603-450725
Web: https://www.jic.ac.uk/people/david-lawson
Email: david.law...@jic.ac.uk




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


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




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

[ccp4bb] DIALS 2.0: from images to MTZ files with DIALS

[Winter, Graeme (DLSLtd,RAL,LSCI)]

Dear ccp4bb

We are pleased to announce the release of - DIALS 2.0: a complete toolkit for 
processing of X-ray diffraction data from area detector images through to 
scaled intensities - free to all users and every line of code available for 
inspection at https://github.com/dials/dials. 

Thanks to the efforts of everyone in the team we are please to announce the 
release of DIALS 2.0 for processing of crystallographic rotation data. This 
includes a large number of changes in particular:

• symmetry determination and scaling - used by default in xia2
• flexible workflows for challenging data
• improvements in speed across for all main steps in the analysis
• more consistent output file naming
• multi-crystal analysis with cosym and xia2.multiplex
• Python 3 compatible code (experimental: will be fully supported in 
2.1)

As always we are constantly working on bug fixes and improvements so the 
current release is version 2.0.2. The binaries for download can be found at:

Downloads: https://dials.github.io/installation.html

With the tutorial documentation at:

Documentation at: https://dials.github.io 

If you have any problems please feel free to log issues at:

Issues: https://github.com/dials/dials/issues 

Or drop us a line at dials-supp...@lists.sourceforge.net. DIALS 2 will be 
included in the forthcoming CCP4 7.1 release. 

This work is only possible thanks to the support of institutions and funding 
agencies:

Diamond Light Source
CCP4 
Biostruct-X project No. 283570 (EU FP7)
Wellcome Trust (Grant No. 202933/Z/16/Z) 
US National Institutes of Health grants GM095887 and GM117126

Which in turn reflects the support offered from the community for our efforts, 
so thank you. 

Sent on behalf of the DIALS development group.
-- 
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




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

Re: [ccp4bb] Xray-dataset usable despite low completeness ?

[Winter, Graeme (DLSLtd,RAL,LSCI)]

The data are > 90% complete at low resolution, where the completeness is more 
important, so this is probably fine - you would  probably benefit from better 
detector placement in the future as the data are good to the edge. 

Was the detector offset or just too far away? 120° for an oP lattice should be 
relatively complete - as appears to be the case for low angle data here. 

The reflections you have measured are almost certainly a better estimate of F^2 
than 0, which is what you are saying if you do throw them away :-) 

Best wishes Graeme

> On 25 Nov 2019, at 13:11, Matthias Oebbeke  
> wrote:
> 
> Dear ccp4 Bulletin Board,
> 
> I collected a dataset at a synchrotron beamline and got the statistics 
> (CORRECT.LP) after processing (using xds) shown in the attached pdf-file.
> 
> Do you think this dataset is usable, due to its low completeness? As you can 
> see in the attached file the completeness is just 50% in the highest 
> resolution shell, whereas the I over Sigma is above 2 and also the CC 1/2 
> (80%) and the R factors (36.8%) have reasonable values. Furthermore the 
> overall statistic are good regarding R factor, CC 1/2 and I over Sigma. The 
> only problem seems to be the completeness. If I would set the cut-off at a 
> lower resolution to get good completeness, I would throw away nearly half of 
> my reflections.
> 
> I'm happy to here your opinion. In Addition to that: The space group is 
> orthorhombic and the dataset was collected over 120° using fine slicing 
> (0.1°).
> 
> 
> Best regards,
> 
> Matthias Oebbeke
> 
> 
> -- 
> Matthias Oebbeke, M.Sc.
> Research Group of Professor Dr. G. Klebe
> Institute of Pharmaceutical Chemistry
> Philipps-University Marburg
> Marbacher Weg 6, 35032 Marburg, Germany
> Phone: +49-6421-28-21392
> Mail: oebbe...@staff.uni-marburg.de
> www.agklebe.de
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> 


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




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