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

[Ian Tickle]

Hi Graeme

No it looks like the problem is some network setting on David's side since
I can submit David's data to the STARANISO server with no problem.  The
only thing to be aware of is that when submitting scaled unmerged data the
checkbox "*Check* here if the data are unmerged but already scaled, ..."
must be checked.

Cheers

-- Ian


On Tue, 14 Jan 2020 at 10:11, Winter, Graeme (DLSLtd,RAL,LSCI) <
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) 
> 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&A=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&A=1
>



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

Re: [ccp4bb] AW: [EXTERNAL] [ccp4bb] An error in the IUCr Online Dictionary of Crystallography

[Ian Tickle]

It's a Wiki so anyone can edit it.  I think you just have to create an
account here:

https://dictionary.iucr.org/index.php?title=Special:CreateAccount&returnto=Real-space+correlation+coefficient

Note that you must have an entry in the World Directory of
Crystallographers, otherwise your Username will be deleted from the list of
contributors by the webmaster.

Cheers

-- Ian


On Tue, 10 Mar 2020 at 14:56, Schreuder, Herman /DE <
herman.schreu...@sanofi.com> wrote:

> Dear Gerhard,
> By clicking on the "Actions" button, I discovered that the contribution
> comes from Brian McMahon. Maybe you could contact him about this?
> Best regards,
> Herman
>
>
> -Ursprüngliche Nachricht-
> Von: CCP4 bulletin board  Im Auftrag von Gerard
> Bricogne
> Gesendet: Dienstag, 10. März 2020 15:16
> An: CCP4BB@JISCMAIL.AC.UK
> Betreff: [EXTERNAL] [ccp4bb] An error in the IUCr Online Dictionary of
> Crystallography
>
> EXTERNAL : Real sender is  owner-ccp...@jiscmail.ac.uk
>
>
>
> Dear all,
>
>  While we are all discussing how to "push the frontiers" of our field,
> there seem to be some dark and dusty corners in the documentation of some
> basic notions. For instance the formula for the real-space correlation
> coefficient given at
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dictionary.iucr.org_Real-2Dspace-5Fcorrelation-5Fcoefficient&d=DwIBAg&c=Dbf9zoswcQ-CRvvI7VX5j3HvibIuT3ZiarcKl5qtMPo&r=HK-CY_tL8CLLA93vdywyu3qI70R4H8oHzZyRHMQu1AQ&m=1AJ1T0r6mgUdK4idVKIjexWpgp_ApLYGh_-nN1mePPo&s=MizVfSbJiL7RRu5wYQy9khDyX9qrR2dEs_vzAIdQiHk&e=
>
> is completely garbled. The absolute value signs in the denominator are
> superfluous, although harmless since we are dealing with real numbers, but
> the numerator is wrong in two respects:
>
>  1. there should not be absolute values around the deviations from the
> mean of the two types of densities;
>
>  2. the expression should be a single summation of products of those
> two
> types of deviation, not a product of single sums!
>
> Does anyone know how to get this corrected?
>
>
>  With best wishes,
>
>   Gerard.
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jiscmail.ac.uk_cgi-2Dbin_webadmin-3FSUBED1-3DCCP4BB-26A-3D1&d=DwIBAg&c=Dbf9zoswcQ-CRvvI7VX5j3HvibIuT3ZiarcKl5qtMPo&r=HK-CY_tL8CLLA93vdywyu3qI70R4H8oHzZyRHMQu1AQ&m=1AJ1T0r6mgUdK4idVKIjexWpgp_ApLYGh_-nN1mePPo&s=f__j9qvpduOnjZB_eN7PR8aDuZisD5CYx78oJ2IzXp8&e=
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
>



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

Re: [ccp4bb] Change map handedness

[Ian Tickle]

A file does not have a handedness, it's just a list of numbers.  So the
pedantic answer is that since it doesn't have a handedness you need do
nothing to change it!

I assume that what you mean is that you want to change the handedness of
the _visual interpretation_ of the file.  That's a different story
altogether since it involves your own visual perception!

Eleanor's trick with the phases will do it if you then view the map in the
same way as you were doing before.

Or you could keep the file the same and view a mirror image of the map.
Eugene has already suggested using a mirror which reverses either the X or
Y axis depending on where you place the mirror.

The obvious and interesting alternative is to reverse the Z axis.  In the
days when we plotted maps on a stack of transparent sheets it was easy: you
just reversed the order of the sheets!  In fact you had to do exactly that
since the plastic molecular model was viewed in a half-silvered mirror
placed in front of the map ("Richard's box", a.k.a. "Fred's Folly":
https://en.wikipedia.org/wiki/Frederic_M._Richards ).

Now a computer screen being a 2-D object obviously doesn't have a Z axis so
you can't reverse it!  However we get the _impression_ of depth in our
brain by using stereo or depth cueing, so you would need to reverse one of
those (maybe a switch on the glasses controller?).

Depth cueing is obtained by having objects that are supposed to be nearer
to you brighter than ones that are supposed to be further away.  So all
need to do is convince your brain that the opposite is true!

Note that all the solutions that reverse the image of the map will also
reverse the image of the structure which may not be what you want.  In that
case Eleanor's solution which results in only reversing the image of the
map is probably the right one.

Oh and happy April 1st to all!

Cheers

-- Ian


On Wed, 1 Apr 2020 at 13:56, Andre LB Ambrosio  wrote:

> Dear all,
> is it possible to generate a mirror image of an existing .ccp4 map file?
> Many thanks in advance.
>
> --
> Andre LB Ambrosio
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
>



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

Re: [ccp4bb] Using SFall for map conversion

[Ian Tickle]

Hi, that would have to be a very old map!  I remember implementing the
auto-byte swap for VMS (necessary as we had both a Convex C220 running Unix
and a VAX 11/750)!

In fact the Convex was rescued from scrap by Jim Austin and is still
working: http://www.corestore.org/convex.htm

Cheers

-- Ian




Cheers

-- Ian


On Fri, 15 May 2020 at 09:24, Philippe BENAS <
0d88e888355a-dmarc-requ...@jiscmail.ac.uk> wrote:

> Dear Bernhard,
>
> Is it an old map ?
>
> Back to the old VAX times I had to dump CCP4 maps to ascii map files, then
> swap bytes from VAX-DOS to Unix before converting them again to a CCP4 map
> format (I think I was using mapman from USF) on a Unix workstation and be
> able to read them in Frodo-Strasbourg or O.
>
> At least you could give it a shot and the ascii map file would help you
> figuring out the issue by a visual inspection of the header and sections.
>
> All the best,
> Philippe
>
> --
> Philippe BENAS, Ph.D.
>
> ARN UPR 9002 CNRS
> IBMC Strasbourg
> 2, Allée Konrad Röntgen
> F-67084 STRASBOURG cedex
> +33.3.8841.7109
> E-mails: p.be...@ibmc-cnrs.unistra.fr, philippe_be...@yahoo.fr
> URLs: http://www-ibmc.u-strasbg.fr/ ,
> http://www-ibmc.u-strasbg.fr/spip-arn/
> --
>
>
>
> Le jeudi 14 mai 2020 à 22:45:09 UTC+2, Bernhard Rupp <
> hofkristall...@gmail.com> a écrit :
>
>
> Hi Fellows,
>
>
>
> I am failing on conversion of a ccp4 map to mtz using Sfall
>
>
>
> I provide as a scale reference a mtz with FP SIGFP and R free
>
>
>
> All cell constants and SG 20 and map headers seem to agree.
>
>
>
> But I receive following warning:
>
>
>
> *** WARNING - your map spacegroup is different to the program default one
> ***
>
>
>
> and later
>
>
>
> >> CCP4 library signal library_file:Cannot open file (Warning)
>
> raised in tmpfile() failed, opening normal file instead. <<
>
> INPUT X USED AS  X
>
> INPUT Y USED AS  Z
>
> INPUT Z USED AS  Y
>
>
>
> Which then leads to the imho - given above- justified complaint:
>
>
>
> Check map header agrees with fixed requirements for SFcalc for this
> spacegroup.
>
> Check Nxyz 180 200 120180 200 120
>
>
>
> Check map header agrees with fixed requirements for SFcalc for this
> spacegroup.
>
> Check Iuvw   3   2   1  3   1   2
>
> 
>
> SFALL:    Fatal disagreement between input info and map header
>
>
>
> How do I fix this ?
>
>
>
> In principle all the information is there to do the job…
>
>
>
> Many thx, BR
>
> --
>
> Bernhard Rupp
>
> Crystallographiae Vindicis Militum Ordo
>
> http://www.hofkristallamt.org/
>
> b...@hofkristallamt.org
>
> +1 925 209 7429
>
> +43 676 571 0536
>
> --
>
> Many plausible ideas vanish
>
> at the presence of thought
>
> --
>
>
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
>



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

Re: [ccp4bb] Using SFall for map conversion

[Ian Tickle]

It worked perfectly, no-one even noticed the bytes being swapped :)

I.


On Fri, 15 May 2020 at 22:37, Eleanor Dodson <
176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk> wrote:

> No no please no!!! How I hated the byte swap.. most people used VAXy
> things - York didn’t - our bytes were not your bytes  stuff of
> nightmares...
>
> On Fri, 15 May 2020 at 22:25, Jonathan Cooper <
> 0c2488af9525-dmarc-requ...@jiscmail.ac.uk> wrote:
>
>> Ian, I can, as a not very scientific footnote, confirm that Jim Austin
>> still has your Convex on his farm and, it seems, most of the manuals:
>>
>> http://u.cubeupload.com/jbcooper/smallIMGP0087.jpg
>> http://u.cubeupload.com/jbcooper/smallIMGP0086.jpg
>> http://u.cubeupload.com/jbcooper/smallIMGP0078.jpg
>> http://u.cubeupload.com/jbcooper/smallIMGP0077.jpg
>> http://u.cubeupload.com/jbcooper/smallIMGP0089.jpg
>> http://u.cubeupload.com/jbcooper/smallIMGP0084.jpg
>> http://u.cubeupload.com/jbcooper/smallIMGP0103.jpg
>> http://u.cubeupload.com/jbcooper/smallIMGP0110.jpg
>>
>> He also has at least one of the ex-bbk Evans & Sutherland PS300's:
>>
>> http://u.cubeupload.com/jbcooper/smallIMGP0091.jpg
>> http://u.cubeupload.com/jbcooper/smallIMGP0093.jpg
>>
>> A few cobwebs, but pretty good going really for a 'former' pig-shed!! Not
>> sure what happened to the 11/750, though... School of Pharmacy rings a
>> bell??
>>
>> None of this matters, but I just thought you might like to practice some
>> 'big-iron' byte-swapping again, and if so, York is the place to go, after
>> covid-19, of course ;-0 ;-0
>> On Friday, 15 May 2020, 10:47:40 BST, Ian Tickle 
>> wrote:
>>
>>
>>
>> Hi, that would have to be a very old map!  I remember implementing the
>> auto-byte swap for VMS (necessary as we had both a Convex C220 running Unix
>> and a VAX 11/750)!
>>
>> In fact the Convex was rescued from scrap by Jim Austin and is still
>> working: http://www.corestore.org/convex.htm
>>
>> Cheers
>>
>> -- Ian
>>
>>
>>
>>
>> Cheers
>>
>> -- Ian
>>
>>
>> On Fri, 15 May 2020 at 09:24, Philippe BENAS <
>> 0d88e888355a-dmarc-requ...@jiscmail.ac.uk> wrote:
>>
>> Dear Bernhard,
>>
>> Is it an old map ?
>>
>> Back to the old VAX times I had to dump CCP4 maps to ascii map files,
>> then swap bytes from VAX-DOS to Unix before converting them again to a CCP4
>> map format (I think I was using mapman from USF) on a Unix workstation and
>> be able to read them in Frodo-Strasbourg or O.
>>
>> At least you could give it a shot and the ascii map file would help you
>> figuring out the issue by a visual inspection of the header and sections.
>>
>> All the best,
>> Philippe
>>
>> --
>> Philippe BENAS, Ph.D.
>>
>> ARN UPR 9002 CNRS
>> IBMC Strasbourg
>> 2, Allée Konrad Röntgen
>> F-67084 STRASBOURG cedex
>> +33.3.8841.7109
>> E-mails: p.be...@ibmc-cnrs.unistra.fr, philippe_be...@yahoo.fr
>> URLs: http://www-ibmc.u-strasbg.fr/ ,
>> http://www-ibmc.u-strasbg.fr/spip-arn/
>> --
>>
>>
>>
>> Le jeudi 14 mai 2020 à 22:45:09 UTC+2, Bernhard Rupp <
>> hofkristall...@gmail.com> a écrit :
>>
>>
>> Hi Fellows,
>>
>>
>>
>> I am failing on conversion of a ccp4 map to mtz using Sfall
>>
>>
>>
>> I provide as a scale reference a mtz with FP SIGFP and R free
>>
>>
>>
>> All cell constants and SG 20 and map headers seem to agree.
>>
>>
>>
>> But I receive following warning:
>>
>>
>>
>> *** WARNING - your map spacegroup is different to the program default one
>> ***
>>
>>
>>
>> and later
>>
>>
>>
>> >>>>>> CCP4 library signal library_file:Cannot open file (Warning)
>>
>> raised in tmpfile() failed, opening normal file instead. <<<<<<
>>
>> INPUT X USED AS  X
>>
>> INPUT Y USED AS  Z
>>
>> INPUT Z USED AS  Y
>>
>>
>>
>> Which then leads to the imho - given above- justified complaint:
>>
>>
>>
>> Check map header agrees with fixed requirements for SFcalc for this
>> spacegroup.
>>
>> Check Nxyz 180 200 120180 200 120
>>
>>
>>
>> Check map header agrees with fixed requirements for SFcalc for this
>> spacegroup.
>

Re: [ccp4bb] Using SFall for map conversion

[Ian Tickle]

I kept the Fortran and C language manuals, and still use them to this day.

I.


On Fri, 15 May 2020 at 22:25, Jonathan Cooper  wrote:

> Ian, I can, as a not very scientific footnote, confirm that Jim Austin
> still has your Convex on his farm and, it seems, most of the manuals:
>
> http://u.cubeupload.com/jbcooper/smallIMGP0087.jpg
> http://u.cubeupload.com/jbcooper/smallIMGP0086.jpg
> http://u.cubeupload.com/jbcooper/smallIMGP0078.jpg
> http://u.cubeupload.com/jbcooper/smallIMGP0077.jpg
> http://u.cubeupload.com/jbcooper/smallIMGP0089.jpg
> http://u.cubeupload.com/jbcooper/smallIMGP0084.jpg
> http://u.cubeupload.com/jbcooper/smallIMGP0103.jpg
> http://u.cubeupload.com/jbcooper/smallIMGP0110.jpg
>
> He also has at least one of the ex-bbk Evans & Sutherland PS300's:
>
> http://u.cubeupload.com/jbcooper/smallIMGP0091.jpg
> http://u.cubeupload.com/jbcooper/smallIMGP0093.jpg
>
> A few cobwebs, but pretty good going really for a 'former' pig-shed!! Not
> sure what happened to the 11/750, though... School of Pharmacy rings a
> bell??
>
> None of this matters, but I just thought you might like to practice some
> 'big-iron' byte-swapping again, and if so, York is the place to go, after
> covid-19, of course ;-0 ;-0
> On Friday, 15 May 2020, 10:47:40 BST, Ian Tickle 
> wrote:
>
>
>
> Hi, that would have to be a very old map!  I remember implementing the
> auto-byte swap for VMS (necessary as we had both a Convex C220 running Unix
> and a VAX 11/750)!
>
> In fact the Convex was rescued from scrap by Jim Austin and is still
> working: http://www.corestore.org/convex.htm
>
> Cheers
>
> -- Ian
>
>
>
>
> Cheers
>
> -- Ian
>
>
> On Fri, 15 May 2020 at 09:24, Philippe BENAS <
> 0d88e888355a-dmarc-requ...@jiscmail.ac.uk> wrote:
>
> Dear Bernhard,
>
> Is it an old map ?
>
> Back to the old VAX times I had to dump CCP4 maps to ascii map files, then
> swap bytes from VAX-DOS to Unix before converting them again to a CCP4 map
> format (I think I was using mapman from USF) on a Unix workstation and be
> able to read them in Frodo-Strasbourg or O.
>
> At least you could give it a shot and the ascii map file would help you
> figuring out the issue by a visual inspection of the header and sections.
>
> All the best,
> Philippe
>
> --
> Philippe BENAS, Ph.D.
>
> ARN UPR 9002 CNRS
> IBMC Strasbourg
> 2, Allée Konrad Röntgen
> F-67084 STRASBOURG cedex
> +33.3.8841.7109
> E-mails: p.be...@ibmc-cnrs.unistra.fr, philippe_be...@yahoo.fr
> URLs: http://www-ibmc.u-strasbg.fr/ ,
> http://www-ibmc.u-strasbg.fr/spip-arn/
> --
>
>
>
> Le jeudi 14 mai 2020 à 22:45:09 UTC+2, Bernhard Rupp <
> hofkristall...@gmail.com> a écrit :
>
>
> Hi Fellows,
>
>
>
> I am failing on conversion of a ccp4 map to mtz using Sfall
>
>
>
> I provide as a scale reference a mtz with FP SIGFP and R free
>
>
>
> All cell constants and SG 20 and map headers seem to agree.
>
>
>
> But I receive following warning:
>
>
>
> *** WARNING - your map spacegroup is different to the program default one
> ***
>
>
>
> and later
>
>
>
> >>>>>> CCP4 library signal library_file:Cannot open file (Warning)
>
> raised in tmpfile() failed, opening normal file instead. <<<<<<
>
> INPUT X USED AS  X
>
> INPUT Y USED AS  Z
>
> INPUT Z USED AS  Y
>
>
>
> Which then leads to the imho - given above- justified complaint:
>
>
>
> Check map header agrees with fixed requirements for SFcalc for this
> spacegroup.
>
> Check Nxyz 180 200 120180 200 120
>
>
>
> Check map header agrees with fixed requirements for SFcalc for this
> spacegroup.
>
> Check Iuvw   3   2   1  3   1   2
>
> 
>
> SFALL:    Fatal disagreement between input info and map header
>
>
>
> How do I fix this ?
>
>
>
> In principle all the information is there to do the job…
>
>
>
> Many thx, BR
>
> --
>
> Bernhard Rupp
>
> Crystallographiae Vindicis Militum Ordo
>
> http://www.hofkristallamt.org/
>
> b...@hofkristallamt.org
>
> +1 925 209 7429
>
> +43 676 571 0536
>
> --
>
> Many plausible ideas vanish
>
> at the presence of thought
>
> --
>
>
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
>
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
>



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

Re: [ccp4bb] Completeness question

[Ian Tickle]

Hi Robbie

I don't see that anisotropic truncation has anything to do with the low
spherical completeness as compared with the info in the co-ordinate file.
Yes the spherical completeness after anisotropic truncation will be
reduced, but why would it cause it to become inconsistent with that
reported (unless of course the completeness calculations were performed on
two different reflection files)?  Besides, the anisotropy is quite low (Delta-B
eigenvalues: 3.42  -1.95 -1.47) so that couldn't explain it.

I do agree that something has clearly gone wrong with the reflection
deposition for 6RJY.  It could of course go right back to the collection or
processing, but I think it unlikely anyone could solve the structure with
data in this state!  Approximately alternate reflections are missing, but
the pattern of absences does not correspond with any space group.  For
example from MTZDUMP on the reflection file:

   3   1   00.00 21.21  0.22
   3   1   20.00 23.83  0.19
   3   1   40.00 34.71  0.26
   3   1   60.00  9.06  0.11
   3   1   80.00 31.64  0.24
   3   1  100.00 31.22  0.25
   3   1  120.00  1.28  0.39
   3   1  140.00  6.59  0.12
   3   1  160.00 17.58  0.15
   3   1  180.00  3.94  0.18
   3   1  200.00 11.05  0.12
   3   1  220.00 34.24  0.24
   3   1  240.00 12.39  0.14
   3   1  260.00 12.76  0.15
   3   1  280.00 20.80  0.18
   3   1  300.00 23.70  0.19
   3   1  320.00 23.47  0.20
   3   1  340.00 30.50  0.23
   3   1  360.00 10.93  0.22
   3   1  380.00 28.11  0.22
   3   1  400.00 24.41  0.21
   3   1  420.00 11.04  0.21
   3   1  440.00 12.58  0.28
   3   1  470.00 10.54  0.29
   3   1  490.00 10.54  0.23
   3   1  510.00  2.98  0.70
   3   1  530.00  5.84  0.39
   3   1  550.00  9.79  0.27
   3   1  570.00 11.33  0.26
   3   1  590.00  8.99  0.30
   3   1  610.00  1.84  0.76
   3   1  630.00  2.63  0.78
   3   1  650.00  4.91  0.46
   3   1  670.00  3.50  0.64
   3   1  690.00  1.93  0.76
   3   1  710.00  4.57  0.52
   3   1  730.00  1.71  0.73

Note how the pattern switches between (3 1 44) and (3 1 47).

So sometimes k+l = 2n are absent and sometimes k+l = 2n+1 are: this pattern
pervades the whole dataset so the completeness (both spherical and
ellipsoidal) is reduced by a factor of about two.  This makes no sense
in terms of known systematic absences, and certainly not for the reported
space group P212121.  This alternating pattern of absences is of course
extremely unlikely in valid data: normally low completeness arises from
whole missing wedges of data, or cusps, or to a smaller extent detector
gaps, i.e. usually missing data are largely contiguous, not alternating as
here.

I think the only solution here is to get the authors to deposit the data
correctly: is there any commonality of the authors for the structures where
you have noted this problem?

Cheers

-- Ian


On Sat, 30 May 2020 at 09:36, Robbie Joosten 
wrote:

> Hi Everyone,
>
> I've been looking at some recent PDB entries that have much lower
> spherical) completeness than reported in the coordinate file. One reason
> for this is that the data were anisotropicly truncated, another reason is
> some mess-up with the deposition of the reflection data. There is a lot of
> discussion about the former practice and I don't want to go in to that, but
> the second one is obviously an error. Now how do I distinguish these cases?
>
> Sometimes, you can look at the reported number of reflections and compare
> that to the deposited reflection file and you will find that something has
> clearly gone wrong. However, the reported number of reflections is not
> entirely reliable because of other issues so I'd rather not use it. If you
> use PDBpeep (e.g. for 6rjy) you can see something is wrong, but that is
> completely visual. Is there a tool in CCP4 that reports both spherical and
> ellipsoidal completeness (on merged reflection data)? That would make it
> easy to distinguish such cases.
>
> Cheers,
> Robbie
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=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] Completeness question

[Ian Tickle]

Also agree, see http://staraniso.globalphasing.org/deposition_about.html .

Cheers

-- Ian


On Sat, 30 May 2020 at 15:58, Robbie Joosten 
wrote:

> I fully agree. Unfortunately, not everyone does that so cases like I
> described will keep appearing.
>
> Cheers,
> Robbie
>
> On 30 May 2020 16:40, Eleanor Dodson  wrote:
>
> My pennysworth. If you find your maps look better after the
> anisotroy correction use it, but it may be helpful to those wo want to mine
> your data if you deposit the whole sphere..
> eleanor
>
> On Sat, 30 May 2020 at 09:36, Robbie Joosten 
> wrote:
>
> Hi Everyone,
>
> I've been looking at some recent PDB entries that have much lower
> spherical) completeness than reported in the coordinate file. One reason
> for this is that the data were anisotropicly truncated, another reason is
> some mess-up with the deposition of the reflection data. There is a lot of
> discussion about the former practice and I don't want to go in to that, but
> the second one is obviously an error. Now how do I distinguish these cases?
>
> Sometimes, you can look at the reported number of reflections and compare
> that to the deposited reflection file and you will find that something has
> clearly gone wrong. However, the reported number of reflections is not
> entirely reliable because of other issues so I'd rather not use it. If you
> use PDBpeep (e.g. for 6rjy) you can see something is wrong, but that is
> completely visual. Is there a tool in CCP4 that reports both spherical and
> ellipsoidal completeness (on merged reflection data)? That would make it
> easy to distinguish such cases.
>
> Cheers,
> Robbie
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=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/webadmin?SUBED1=CCP4BB&A=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=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] Questions regarding MTZFIX and EDSTATS

[Ian Tickle]

Hi Joao

For all CCP4 programs you need to source your CCP4 setup script.

Cheers

-- Ian


On Mon, 15 Jun 2020 at 15:29, Joao Ramos  wrote:

> Dear CCP4bb,
>
> I'm trying to obtain RSC metrics using the CCP4 program EDSTATS for a
> Phenix refinement job, in order to have a more reliable analysis of model
> quality. From what I read, one should go through the program MTZFIX and
> then create the FFT maps (density and difference maps). However, while
> attempting to run the Phenix output mtz file in MTZFIX, I receive an error
> message saying: "Cannot open environ.def".
>
> My questions are:
> 1) Is the way to go from the Phenix refinement output files to EDSTATS
> described earlier correct? Are there alternative programs included in
> Phenix?
> 2) How to fix the error and run MTZFIX?
>
> I'm currently using the new ccp4 v7.1, in macOS v10.14.5.
>
> Best regards,
> Joao Ramos
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/wa.exe?SUBED1=CCP4BB&A=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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] Questions regarding MTZFIX and EDSTATS

[Ian Tickle]

Hi Joao

The top of the page was cut off in your screenshot so I can't see the
command line you typed.  It would be better to copy/paste the entire text,
including the input command line and the output, into the email rather than
taking a screenshot.  'Cannot open file' most likely means that the input
filename was not typed correctly or the path was not specified correctly if
it's in another directory.  Anyway you really shouldn't be calling the
MTZFIX or EDSTATS programs directly.  Using the Perl script 'edstats.pl'
http://www.ccp4.ac.uk/dist/checkout/edstats/edstats.pl is much easier.  It
should be in your path after running the CCP4 setup script.

Cheers

-- Ian


On Mon, 15 Jun 2020 at 18:41, Joao Ramos  wrote:

> Dear Ian,
>
> Thanks for the reply!
>
> I've sourced the setup script, but now I get a 'cannot open file' error
> message (screenshot attached) when trying to run MTZFIX.
>
> Best regards,
> Joao Ramos
>
> Ian Tickle  escreveu no dia segunda, 15/06/2020 à(s)
> 16:57:
>
>>
>> Hi Joao
>>
>> For all CCP4 programs you need to source your CCP4 setup script.
>>
>> Cheers
>>
>> -- Ian
>>
>>
>> On Mon, 15 Jun 2020 at 15:29, Joao Ramos 
>> wrote:
>>
>>> Dear CCP4bb,
>>>
>>> I'm trying to obtain RSC metrics using the CCP4 program EDSTATS for a
>>> Phenix refinement job, in order to have a more reliable analysis of model
>>> quality. From what I read, one should go through the program MTZFIX and
>>> then create the FFT maps (density and difference maps). However, while
>>> attempting to run the Phenix output mtz file in MTZFIX, I receive an error
>>> message saying: "Cannot open environ.def".
>>>
>>> My questions are:
>>> 1) Is the way to go from the Phenix refinement output files to EDSTATS
>>> described earlier correct? Are there alternative programs included in
>>> Phenix?
>>> 2) How to fix the error and run MTZFIX?
>>>
>>> I'm currently using the new ccp4 v7.1, in macOS v10.14.5.
>>>
>>> Best regards,
>>> Joao Ramos
>>>
>>> --
>>>
>>> To unsubscribe from the CCP4BB list, click the following link:
>>> https://www.jiscmail.ac.uk/cgi-bin/wa.exe?SUBED1=CCP4BB&A=1
>>>
>>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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] Questions regarding MTZFIX and EDSTATS

[Ian Tickle]

Hi João

In cases like this it's always a good idea to check whether you can read
the same MTZ file with mtzdmp.  If that fails with the same error message
it means that the pathname/filename was indeed incorrectly specified, or it
could possibly be a permissions issue (the file needs to be given read
permission).

Cheers

Ian


On Mon, 15 Jun 2020, 19:09 Ian Tickle,  wrote:

>
> Hi Joao
>
> The top of the page was cut off in your screenshot so I can't see the
> command line you typed.  It would be better to copy/paste the entire text,
> including the input command line and the output, into the email rather than
> taking a screenshot.  'Cannot open file' most likely means that the input
> filename was not typed correctly or the path was not specified correctly if
> it's in another directory.  Anyway you really shouldn't be calling the
> MTZFIX or EDSTATS programs directly.  Using the Perl script 'edstats.pl'
> http://www.ccp4.ac.uk/dist/checkout/edstats/edstats.pl is much easier.
> It should be in your path after running the CCP4 setup script.
>
> Cheers
>
> -- Ian
>
>
> On Mon, 15 Jun 2020 at 18:41, Joao Ramos 
> wrote:
>
>> Dear Ian,
>>
>> Thanks for the reply!
>>
>> I've sourced the setup script, but now I get a 'cannot open file' error
>> message (screenshot attached) when trying to run MTZFIX.
>>
>> Best regards,
>> Joao Ramos
>>
>> Ian Tickle  escreveu no dia segunda, 15/06/2020 à(s)
>> 16:57:
>>
>>>
>>> Hi Joao
>>>
>>> For all CCP4 programs you need to source your CCP4 setup script.
>>>
>>> Cheers
>>>
>>> -- Ian
>>>
>>>
>>> On Mon, 15 Jun 2020 at 15:29, Joao Ramos 
>>> wrote:
>>>
>>>> Dear CCP4bb,
>>>>
>>>> I'm trying to obtain RSC metrics using the CCP4 program EDSTATS for a
>>>> Phenix refinement job, in order to have a more reliable analysis of model
>>>> quality. From what I read, one should go through the program MTZFIX and
>>>> then create the FFT maps (density and difference maps). However, while
>>>> attempting to run the Phenix output mtz file in MTZFIX, I receive an error
>>>> message saying: "Cannot open environ.def".
>>>>
>>>> My questions are:
>>>> 1) Is the way to go from the Phenix refinement output files to EDSTATS
>>>> described earlier correct? Are there alternative programs included in
>>>> Phenix?
>>>> 2) How to fix the error and run MTZFIX?
>>>>
>>>> I'm currently using the new ccp4 v7.1, in macOS v10.14.5.
>>>>
>>>> Best regards,
>>>> Joao Ramos
>>>>
>>>> --
>>>>
>>>> To unsubscribe from the CCP4BB list, click the following link:
>>>> https://www.jiscmail.ac.uk/cgi-bin/wa.exe?SUBED1=CCP4BB&A=1
>>>>
>>>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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] Questions regarding MTZFIX and EDSTATS

[Ian Tickle]

Hi Joao

Can you post the mtzdmp output?

Cheers

Ian



On Tue, 16 Jun 2020, 09:30 Joao Ramos,  wrote:

> Dear Ian,
>
> I'm trying to use the edstats.pl script but I'm having problems with the
> column labels. mtzdmp can read the mtz file, but edstats.pl gives me a
> message saying that mtzfix cannot find the labels. I'm using a mtz file
> from a refinement job in Phenix.
>
> Best regards,
> Joao Ramos
>
> Ian Tickle  escreveu no dia terça, 16/06/2020 à(s)
> 09:39:
>
>> Hi João
>>
>> In cases like this it's always a good idea to check whether you can read
>> the same MTZ file with mtzdmp.  If that fails with the same error message
>> it means that the pathname/filename was indeed incorrectly specified, or it
>> could possibly be a permissions issue (the file needs to be given read
>> permission).
>>
>> Cheers
>>
>> Ian
>>
>>
>> On Mon, 15 Jun 2020, 19:09 Ian Tickle,  wrote:
>>
>>>
>>> Hi Joao
>>>
>>> The top of the page was cut off in your screenshot so I can't see the
>>> command line you typed.  It would be better to copy/paste the entire text,
>>> including the input command line and the output, into the email rather than
>>> taking a screenshot.  'Cannot open file' most likely means that the input
>>> filename was not typed correctly or the path was not specified correctly if
>>> it's in another directory.  Anyway you really shouldn't be calling the
>>> MTZFIX or EDSTATS programs directly.  Using the Perl script 'edstats.pl
>>> ' http://www.ccp4.ac.uk/dist/checkout/edstats/edstats.pl is much
>>> easier.  It should be in your path after running the CCP4 setup script.
>>>
>>> Cheers
>>>
>>> -- Ian
>>>
>>>
>>> On Mon, 15 Jun 2020 at 18:41, Joao Ramos 
>>> wrote:
>>>
>>>> Dear Ian,
>>>>
>>>> Thanks for the reply!
>>>>
>>>> I've sourced the setup script, but now I get a 'cannot open file' error
>>>> message (screenshot attached) when trying to run MTZFIX.
>>>>
>>>> Best regards,
>>>> Joao Ramos
>>>>
>>>> Ian Tickle  escreveu no dia segunda, 15/06/2020
>>>> à(s) 16:57:
>>>>
>>>>>
>>>>> Hi Joao
>>>>>
>>>>> For all CCP4 programs you need to source your CCP4 setup script.
>>>>>
>>>>> Cheers
>>>>>
>>>>> -- Ian
>>>>>
>>>>>
>>>>> On Mon, 15 Jun 2020 at 15:29, Joao Ramos 
>>>>> wrote:
>>>>>
>>>>>> Dear CCP4bb,
>>>>>>
>>>>>> I'm trying to obtain RSC metrics using the CCP4 program EDSTATS for a
>>>>>> Phenix refinement job, in order to have a more reliable analysis of model
>>>>>> quality. From what I read, one should go through the program MTZFIX and
>>>>>> then create the FFT maps (density and difference maps). However, while
>>>>>> attempting to run the Phenix output mtz file in MTZFIX, I receive an 
>>>>>> error
>>>>>> message saying: "Cannot open environ.def".
>>>>>>
>>>>>> My questions are:
>>>>>> 1) Is the way to go from the Phenix refinement output files to
>>>>>> EDSTATS described earlier correct? Are there alternative programs 
>>>>>> included
>>>>>> in Phenix?
>>>>>> 2) How to fix the error and run MTZFIX?
>>>>>>
>>>>>> I'm currently using the new ccp4 v7.1, in macOS v10.14.5.
>>>>>>
>>>>>> Best regards,
>>>>>> Joao Ramos
>>>>>>
>>>>>> --
>>>>>>
>>>>>> To unsubscribe from the CCP4BB list, click the following link:
>>>>>> https://www.jiscmail.ac.uk/cgi-bin/wa.exe?SUBED1=CCP4BB&A=1
>>>>>>
>>>>>



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

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

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

[Ian Tickle]

I agree about RAID but I would go a lot further.  There seems to be some
confusion here over the correct meaning of 'redundant' as used in a
scientific context.  I don't think looking it up in an English dictionary
is very helpful.  So as has been mentioned the non-scientific and rather
imprecise meanings are "not or no longer needed or useful; superfluous" or
"exceeding what is necessary or natural; superfluous" and "needlessly
repetitive; verbose".  In fact both redundant and abundant have the same
Latin etymology, and redundant literally means 're' (again) + 'unda'
(wave), i.e. 'repeating as a wave'.  The original meaning in English is in
fact 'over-abundant' and is still used in poetry with that meaning (e.g.
"as redundant as the poppies in the field").  There's of course also the
meaning 'dismissal from a job due to a need to reduce the head count' and
from there 'out of work', but that's relatively recent having been coined
by a UK Government official in the 1900s!

The correct and totally precise scientific meaning which is appropriate in
the context of this discussion is to be found here:
https://en.wikipedia.org/wiki/Redundancy_(engineering) .  Note that it
applies equally to both hardware and software engineering:

*R**edundancy* is the duplication of critical components or functions of a
system with the intention of increasing reliability of the system
, usually in the form of a backup or
fail-safe , or to improve actual
system performance.

Nothing there about not or no longer needed or useful, superfluous, needlessly
repetitive, verbose!  Note that 'multiplicity' totally fails to carry the
connotation of increasing the system reliability by duplication (i.e. there
are multiple copies but there's nothing that indicates the justification
for them).  Redundancy occurs in TMR (triple modular redundancy) systems
used (as I guess Bernhard knows well) in triplicated control systems in
commercial aircraft.  I don't know about you but I wouldn't regard the
extra two backup systems in TMR as 'not needed or useful' when I'm an
airline passenger !

https://en.wikipedia.org/wiki/Triple_modular_redundancy

More is always better when it's critical:

https://www.isa.org/standards-and-publications/isa-publications/intech-magazine/2003/october/more-is-always-better-when-its-critical

There's also the question of the same word (redundancy, multiplicity or
whatever) having different meanings according to context.  That's
unavoidable given that the number of concepts that we might want to name
far exceeds the number of words available, so we have to rely heavily on
context when assigning meaning.  We don't say what the context is so the
context must be obvious and unambiguous.  Whether we're talking about RAID
or losing one's job it's obvious what the intended meaning is from the
context because the contexts are totally separate.  The important thing is
that the contexts should be well-separated so that no confusion is
possible.  Graeme says he's not confused by the various meanings of
'multiplicity' but non-crystallographer consumers of Table 1 surely might
be!  The various contexts in which 'multiplicity' is used are certainly not
well-separated and overlap in program outputs and documentation, allowing
plenty of scope for confusion.

In a scientific context 'redundancy' has a unique precise meaning whereas
'multiplicity' has a multiplicity!

BTW I use CCP4/Aimless and 'redundancy' (as you no doubt will have guessed,
because it's the word that unambiguously describes the concept), so
apparently I'm with you lot across the pond on this!

Cheers

-- Ian



On Tue, 30 Jun 2020 at 09:01, David Waterman  wrote:

> Reflections are as "redundant" as the disks in a RAID 0 array
>
> On Tue, 30 Jun 2020, 02:49 James Holton,  wrote:
>
>> What could possibly go wrong?
>>
>> -James Holton
>> MAD Scientist
>>
>> On 6/29/2020 6:17 PM, Edward A. Berry wrote:
>> > Now can we get rid of all the superfluous disks in our RAID? Or at
>> > least not replace them when they fail?
>> >
>> > On 06/29/2020 06:24 PM, Andreas Förster wrote:
>> >> 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 > >> > 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

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

[Ian Tickle]

Yes this seems to be a common misunderstanding, that the meanings of words
such as 'redundancy' have to be the same in an informal non-scientific
context and in a formal technical/scientific context.

So we can say that in an informal context, 'redundancy' means "unnecessary
duplication (or multiplication) without a purpose", and in a formal context
it has come to mean, ever since John von Neumann pioneered the idea in the
1950s, "duplication / multiplication with the express purpose of improving
the reliability of the outcome".  'Multiplicity / multiplication' is
neutral with regard to purpose.

This divergence of meanings should hardly come as a surprise to anyone, and
also not surprisingly the informal meaning tends to be rather ill-defined,
for example 'theory' used informally means "hypothesis, hunch, speculation,
conjecture etc.", whereas in a scientific context it has the precise
meaning "A coherent <https://en.wiktionary.org/wiki/coherent> statement
<https://en.wiktionary.org/wiki/statement> or set of ideas that explains
<https://en.wiktionary.org/wiki/explain> observed
<https://en.wiktionary.org/wiki/observe> facts
<https://en.wiktionary.org/wiki/fact> or phenomena
<https://en.wiktionary.org/wiki/phenomenon> and correctly predicts new
facts or phenomena not previously observed, or which sets out the laws
<https://en.wiktionary.org/wiki/law> and principles of something known or
observed; a hypothesis confirmed by observation, experiment etc." (
https://en.wiktionary.org/wiki/theory).

"The Hypothesis of Evolution" anyone ?

Cheers

-- Ian




On Tue, 30 Jun 2020 at 14:30, Phil Evans  wrote:

> I changed the annotation from “Redundancy” to “Multiplicity” in Scala,
> later in Aimless, after I was taken to task by Elspeth Garman with the
> argument as stated, that if it’s redundant why did you bother to measure it?
>
> (this one could run and run …)
>
> Phil
>
> > On 30 Jun 2020, at 14:07, Ian Tickle  wrote:
> >
> >
> > I agree about RAID but I would go a lot further.  There seems to be some
> confusion here over the correct meaning of 'redundant' as used in a
> scientific context.  I don't think looking it up in an English dictionary
> is very helpful.  So as has been mentioned the non-scientific and rather
> imprecise meanings are "not or no longer needed or useful; superfluous" or
> "exceeding what is necessary or natural; superfluous" and "needlessly
> repetitive; verbose".  In fact both redundant and abundant have the same
> Latin etymology, and redundant literally means 're' (again) + 'unda'
> (wave), i.e. 'repeating as a wave'.  The original meaning in English is in
> fact 'over-abundant' and is still used in poetry with that meaning (e.g.
> "as redundant as the poppies in the field").  There's of course also the
> meaning 'dismissal from a job due to a need to reduce the head count' and
> from there 'out of work', but that's relatively recent having been coined
> by a UK Government official in the 1900s!
> >
> > The correct and totally precise scientific meaning which is appropriate
> in the context of this discussion is to be found here:
> https://en.wikipedia.org/wiki/Redundancy_(engineering) .  Note that it
> applies equally to both hardware and software engineering:
> >
> > Redundancy is the duplication of critical components or functions of a
> system with the intention of increasing reliability of the system, usually
> in the form of a backup or fail-safe, or to improve actual system
> performance.
> >
> > Nothing there about not or no longer needed or useful, superfluous,
> needlessly repetitive, verbose!  Note that 'multiplicity' totally fails to
> carry the connotation of increasing the system reliability by duplication
> (i.e. there are multiple copies but there's nothing that indicates the
> justification for them).  Redundancy occurs in TMR (triple modular
> redundancy) systems used (as I guess Bernhard knows well) in triplicated
> control systems in commercial aircraft.  I don't know about you but I
> wouldn't regard the extra two backup systems in TMR as 'not needed or
> useful' when I'm an airline passenger !
> >
> > https://en.wikipedia.org/wiki/Triple_modular_redundancy
> >
> > More is always better when it's critical:
> >
> >
> https://www.isa.org/standards-and-publications/isa-publications/intech-magazine/2003/october/more-is-always-better-when-its-critical
> >
> > There's also the question of the same word (redundancy, multiplicity or
> whatever) having d

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

[Ian Tickle]

Hi Navdeep

Yes good point, the principle of redundancy (though they wouldn't have used
that term!) has a very long history, but von Neumann did more than anyone
before him to formalise it:

http://www.cyclify.com/wiki/images/a/af/Von_Neumann_Probabilistic_Logics_and_the_Synthesis_of_Reliable_Organisms_from_Unreliable_Components.pdf

Cheers

-- Ian


On Thu, 2 Jul 2020 at 11:58, Navdeep Sidhu  wrote:

> Dear Ian,
>
> You seem to be slightly off there: The successful use of repeating
> observations to reduce (especially systematic) observational error
> predates von Neumann by at least 4 centuries.
>
> One of the first instances of its use was in the 1500s, due to a migrant
> scientist working in Denmark and Prague, Czech Republic: Tycho Brahe,
> whom "the divine goodness [had] given to us" (Kepler).
>
> Best regards,
> Navdeep
>
>
> ---
> On 01.07.20 17:38, Ian Tickle wrote:
> >
> > Yes this seems to be a common misunderstanding, that the meanings of
> > words such as 'redundancy' have to be the same in an informal
> > non-scientific context and in a formal technical/scientific context.
> >
> > So we can say that in an informal context, 'redundancy' means
> > "unnecessary duplication (or multiplication) without a purpose", and in
> > a formal context it has come to mean, ever since John von Neumann
> > pioneered the idea in the 1950s, "duplication / multiplication with the
> > express purpose of improving the reliability of the outcome".
> > 'Multiplicity / multiplication' is neutral with regard to purpose.
> >
> > This divergence of meanings should hardly come as a surprise to anyone,
> > and also not surprisingly the informal meaning tends to be rather
> > ill-defined, for example 'theory' used informally means "hypothesis,
> > hunch, speculation, conjecture etc.", whereas in a scientific context it
> > has the precise meaning "A coherent
> > <https://en.wiktionary.org/wiki/coherent> statement
> > <https://en.wiktionary.org/wiki/statement> or set of ideas that explains
> > <https://en.wiktionary.org/wiki/explain> observed
> > <https://en.wiktionary.org/wiki/observe> facts
> > <https://en.wiktionary.org/wiki/fact> or phenomena
> > <https://en.wiktionary.org/wiki/phenomenon> and correctly predicts new
> > facts or phenomena not previously observed, or which sets out the laws
> > <https://en.wiktionary.org/wiki/law> and principles of something known
> > or observed; a hypothesis confirmed by observation, experiment etc."
> > (https://en.wiktionary.org/wiki/theory).
> >
> > "The Hypothesis of Evolution" anyone ?
> >
> > Cheers
> >
> > -- Ian
> >
> >
> >
> >
> > On Tue, 30 Jun 2020 at 14:30, Phil Evans  > <mailto:p...@mrc-lmb.cam.ac.uk>> wrote:
> >
> > I changed the annotation from “Redundancy” to “Multiplicity” in
> > Scala, later in Aimless, after I was taken to task by Elspeth Garman
> > with the argument as stated, that if it’s redundant why did you
> > bother to measure it?
> >
> > (this one could run and run …)
> >
> > Phil
> >
> > > On 30 Jun 2020, at 14:07, Ian Tickle  > <mailto:ianj...@gmail.com>> wrote:
> > >
> > >
> > > I agree about RAID but I would go a lot further.  There seems to
> > be some confusion here over the correct meaning of 'redundant' as
> > used in a scientific context.  I don't think looking it up in an
> > English dictionary is very helpful.  So as has been mentioned the
> > non-scientific and rather imprecise meanings are "not or no longer
> > needed or useful; superfluous" or "exceeding what is necessary or
> > natural; superfluous" and "needlessly repetitive; verbose".  In fact
> > both redundant and abundant have the same Latin etymology, and
> > redundant literally means 're' (again) + 'unda' (wave), i.e.
> > 'repeating as a wave'.  The original meaning in English is in fact
> > 'over-abundant' and is still used in poetry with that meaning (e.g.
> > "as redundant as the poppies in the field").  There's of course also
> > the meaning 'dismissal from a job due to a need to reduce the head
> > count' and from there 'out of work', but that's relatively recent
> > having been coined by a UK Government official in the 1900s!
> > >

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

[Ian Tickle]

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 (and see that there are
> shortcomings with both “multiplicity” and “redundancy") and I agree with
> much of what’s been said most recently in this thread.
>
> BTW, just because the Physics definition of a
> measurement/quantity/whatever is given on wikipedia (or elsewhere, for that
> matter), it doesn’t mean that’s what we (crystallographers, structural
> biologists, etc) should use without question. If you check
>
> https://en.wikipedia.org/wiki/Reflection_(physics)
>
> you will find no mention of diffraction maxima corresponding to
> reflections except a link to a page on diffraction. Or maybe we should
> slavishly follow the Physicists and use another term…
>
> H
>
> > On 2 Jul 2020, at 10:41, Schreuder,

Re: [ccp4bb] Quote source inquiry

[Ian Tickle]

Hi,

There's one big difference between macromolecular and small molecule
refinement: except at ultra-high resolution the bond lengths in the former
are almost always strongly restrained, whereas those in the latter are
almost without exception completely unrestrained (except possibly bond
lengths to H atoms in XRD).  In other words, MX accurately determines the
orthogonal atomic co-ordinates, whereas XRD accurately determines their
fractional co-ordinates (it's no accident that the different programs
output co-ordinates in those formats).

This means that since the cell dimensions are then used to convert
fractional to orthogonal in XRD, the final bond lengths will be much more
sensitive to errors in the cell dimensions, so having accurate cell
dimensions is more critical if you want accurate bond lengths (e.g. for use
as restraints in MX!).  Obviously there's also a limit to the errors in the
cell dimensions that can be tolerated in MX: large errors will lead to
errors in calculated d* values and hence the scattering factors, which is
likely to have a significant effect, and there may be issues with VdW
repulsions if the cell is too small (though it's relatively easy for the
structure to accommodate that).

As Philip pointed out, the bond lengths will be totally insensitive to
errors in the uncertainties of the cell dimensions, whether artificially
introduced or poorly estimated from the data.  I don't know of any MX
refinement program (other than Shel-X) that takes the uncertainties in the
cell dimensions into account, even assuming that you have accurate values
for them.

Also you should be careful not to confuse uncertainty (imprecision) with
error (inaccuracy).  The 'standard uncertainty' (s.u.) is the experimental
estimate of the 'standard deviation' (in the error) (
https://physics.nist.gov/cgi-bin/cuu/Info/Constants/definitions.html), and
the old term 'estimated standard deviation' (e.s.d.) was deprecated in 1993
(http://scripts.iucr.org/cgi-bin/paper?S0108767395002340).  You can have an
error in an uncertainty (which is what you were introducing in your test),
but you can't have an uncertainty in an error, since errors are by their
nature unknown anyway!

It goes without saying that it's not a good idea to use bond lengths from a
restrained refinement as restraints in other refinements!

Cheers

-- Ian


On Wed, 15 Jul 2020 at 17:56, Jeffrey B Bonanno <
jeffrey.bona...@einsteinmed.org> wrote:

> Hi Phil,
>
>
>
> Being young and impressionable, I only changed ZERR, and you are quiet
> right the result is the rigorous and expected error propagation of shelxl.
> Of course the more fun experiment would be in systematically changing
> various values in UNIT to watch the molecule distort.
>
>
>
> Hope all is well,
>
> jbb
>
>
>
> Jeffrey B. Bonanno, Ph.D.
>
> Department of Biochemistry
>
> Albert Einstein College of Medicine
>
> 1300 Morris Park Avenue
>
> Bronx, NY 10461
>
> off. 718-430-2452 fax. 718-430-8565
>
> email jeffrey.bona...@einsteinmed.org
>
>
>
> *From:* Jeffrey, Philip D. 
> *Sent:* Wednesday, July 15, 2020 12:47 PM
> *To:* CCP4BB@JISCMAIL.AC.UK; Jeffrey B Bonanno <
> jeffrey.bona...@einsteinmed.org>
> *Subject:* Re: [ccp4bb] Quote source inquiry
>
>
>
> *CAUTION: This email comes from an external source; the attachments and/or
> links may compromise our secure environment. Do not open or click on
> suspicious emails. Please click on the “Phish Alert” button on the top
> right of the Outlook dashboard to report any suspicious emails.*
>
> :: took a working dataset and increased (only) the error on unit cell
> dimensions in the instruction file for the final round of full matrix ::
> least squares refinement in shelxl. Sure enough, the errors on the bonds
> and angles shot up. I was more careful
>
>
>
> Question: did you change the unit cell dimensions (UNIT) or the reported
> standard error in the unit cell dimensions (ZERR) ?  If just the latter
> don't you think that the error propagation is just a factor of SHELXL
> converting from fractional to orthogonal coordinates to give you bond
> lengths and bond angles (i.e. the bonds and angles would be numerically the
> same, but the estimated error associated with them would be higher).  Did
> the e.s.d.'s of the actual coordinates in fractional space change ?
>
>
>
> Phil Jeffrey
>
> Princeton
> --
>
> *From:* CCP4 bulletin board  on behalf of Jeffrey
> B Bonanno 
> *Sent:* Wednesday, July 15, 2020 12:36 PM
> *To:* CCP4BB@JISCMAIL.AC.UK 
> *Subject:* Re: [ccp4bb] Quote source inquiry
>
>
>
> Hi Gerard and Bernhard,
>
> As a postdoc in an unnamed small molecule lab, I was instructed by my lab
> head to get better unit cell estimates prior to data collection owing to
> error propagation from the uncertainty on cell dimensions through to the
> esd on atomic bond lengths and angles when refining in shelxl. To verify
> this (what, you believed everything your postdoc advisor told you?), I took
> a working dataset and

Re: [ccp4bb] Quote source inquiry

[Ian Tickle]

Hi Robbie

Yes I was (perhaps rashly!) assuming that the data are properly weighted
relative to the restraints.

Thanks for pointing that out.

Cheers

-- Ian


On Wed, 15 Jul 2020 at 20:23, Robbie Joosten 
wrote:

> Hi Ian,
>
> Errors in cell dimensions can have a large effect in MX with certain
> refinement doctrines. The school of "bond length rmsd must be $NUMBER"
> (which is still going strong unfortunately) will suffer from poor R-factors
> because the target cannot be satisfied without harming the fit to the data.
> At the same time if you have a a more relaxed approach to restraints than
> you might find systematic deviations in bond lengths. A test for that has
> been in WHAT_CHECK for decades and it actually works surprisingly well to
> detect cell dimension problems. That said, the problem is uncommon now.
>
> Cheers,
> Robbie
>
> > -Original Message-
> > From: CCP4 bulletin board  On Behalf Of Ian
> > Tickle
> > Sent: Wednesday, July 15, 2020 20:25
> > To: CCP4BB@JISCMAIL.AC.UK
> > Subject: Re: [ccp4bb] Quote source inquiry
> >
> >
> > Hi,
> >
> > There's one big difference between macromolecular and small molecule
> > refinement: except at ultra-high resolution the bond lengths in the
> former
> > are almost always strongly restrained, whereas those in the latter are
> almost
> > without exception completely unrestrained (except possibly bond lengths
> to
> > H atoms in XRD).  In other words, MX accurately determines the orthogonal
> > atomic co-ordinates, whereas XRD accurately determines their fractional
> co-
> > ordinates (it's no accident that the different programs output
> co-ordinates in
> > those formats).
> >
> > This means that since the cell dimensions are then used to convert
> fractional
> > to orthogonal in XRD, the final bond lengths will be much more sensitive
> to
> > errors in the cell dimensions, so having accurate cell dimensions is more
> > critical if you want accurate bond lengths (e.g. for use as restraints
> in MX!).
> > Obviously there's also a limit to the errors in the cell dimensions that
> can be
> > tolerated in MX: large errors will lead to errors in calculated d*
> values and
> > hence the scattering factors, which is likely to have a significant
> effect, and
> > there may be issues with VdW repulsions if the cell is too small (though
> it's
> > relatively easy for the structure to accommodate that).
> >
> > As Philip pointed out, the bond lengths will be totally insensitive to
> errors in
> > the uncertainties of the cell dimensions, whether artificially
> introduced or
> > poorly estimated from the data.  I don't know of any MX refinement
> > program (other than Shel-X) that takes the uncertainties in the cell
> > dimensions into account, even assuming that you have accurate values for
> > them.
> >
> > Also you should be careful not to confuse uncertainty (imprecision) with
> > error (inaccuracy).  The 'standard uncertainty' (s.u.) is the
> experimental
> > estimate of the 'standard deviation' (in the error)
> > (https://physics.nist.gov/cgi-bin/cuu/Info/Constants/definitions.html),
> and
> > the old term 'estimated standard deviation' (e.s.d.) was deprecated in
> 1993
> > (http://scripts.iucr.org/cgi-bin/paper?S0108767395002340).  You can have
> > an error in an uncertainty (which is what you were introducing in your
> test),
> > but you can't have an uncertainty in an error, since errors are by their
> nature
> > unknown anyway!
> >
> > It goes without saying that it's not a good idea to use bond lengths
> from a
> > restrained refinement as restraints in other refinements!
> >
> > Cheers
> >
> > -- Ian
> >
> >
> > On Wed, 15 Jul 2020 at 17:56, Jeffrey B Bonanno
> >  > <mailto:jeffrey.bona...@einsteinmed.org> > wrote:
> >
> >
> >   Hi Phil,
> >
> >
> >
> >   Being young and impressionable, I only changed ZERR, and you are
> > quiet right the result is the rigorous and expected error propagation of
> > shelxl. Of course the more fun experiment would be in systematically
> > changing various values in UNIT to watch the molecule distort.
> >
> >
> >
> >   Hope all is well,
> >
> >   jbb
> >
> >
> >
> >   Jeffrey B. Bonanno, Ph.D.
> >
> >   Department of Biochemistry
> >
> >   Albert Einstein College of Medicine
> >
> >   1300 Morris Park Avenue
&g

Re: [ccp4bb] Question about P3, H3 and R3 space groups

[Ian Tickle]

Hi David

The problem is that the PDB incorrectly used the H lattice symbol (without
consulting any crystallographers AFAIK) for the hexagonal R-centred cell
when it had already been in use for many years for the triply-primitive
setting of P3, so now we have this confusion between MX & XRD/powder
usage.  It's probably now too late to do anything about it.  Simply put: in
XRD/powder software H3 is #143 as originally specified in IUCr Int. Tab.;
in MX software H3 is #146.

What should have been used are the Hermann-Mauguin symbols for the two R3
cells: R3:r and R3:h (see the syminfo.lib file).

This is a constant confusion between the standard symbol (i.e. one of the
230 space-groups in their standard settings) and the setting symbols.
Other common examples are space group #5 with standard symbol C2 which has
a number of alternative settings A121, B112, C121, I121 etc., and standard
symbol P21212 with settings P22121, P21221 and P21212, all of which are
equally valid.  The conventional IUCr choice of setting is determined by
the relative cell lengths (as far as possible c >= b >= a) and the cell
angle (which in monoclinic cells should always be chosen >= 90 and closest
to 90).  In practical crystallography it's the setting symbol that matters;
the standard symbol is relevant only for classification, so in practice
only the setting symbols should be used/

Cheers

--  Ian


On Wed, 22 Jul 2020 at 12:32, David Vizarraga Revuelto 
wrote:

> Dear all,
>
> Let me ask a question about the P3,H3, R3 space group annotations.
> I had the idea that H3 was the recommended annotation for the hexagonal
> representation of R3 (space group number 146). However, in the Birbeck
> space groups web page (attached) H3 is associated with the space group
> number 143 corresponding to P3. Similarly for all the other H groups
> assigned in the page. Moreover in the web page none of the R space groups
> is assigned to an H annotation.
>
> H3 corresponds to 143 or  to 146?
> Is there a space group 154 annotated as H32 1 2?
>
> Many thanks.
>
>
>
> "Note that the figure showing the relationship between primitive and
> R-centred rhomohedral cells with hexagonal axes is clickable
>
> Rhombohedral with Hexagonal axes
> 146. *R* 3  148. *R* -3
>  155. *R* 3 2
>  160. *R* 3 *m*
>  161. *R* 3 *c*
>  166. *R* -3 *m*
> 
> 167. *R* -3 *c* 
> H-centred Trigonal
> 143. *H* 3  144. *H* 31
>  145. *H* 32
>  147. *H* -3
>  149. *H* 3 2 1
>  150. *H* 3 1 2
> 
> 151. *H* 31 2 1  152. *H*
>  31 1 2  153. *H* 32 2 1
>  154. *H* 32 1 2
>  156. *H* 3 1 *m*
>  157. *H* 3 *m* 1
> 
> 158. *H* 3 1 *c*  159. *H*
>  3 *c* 1  162. *H* -3 *m*
>  1  163. *H* -3 *c* 1
>  164. *H* -3 1 *m*
>  165. *H* -3 1 *c*
> 
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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] Question about P3, H3 and R3 space groups

[Ian Tickle]

Hi Eleanor

H3 #143 is (and always has been) a triply-primitive cell setting of P3.

http://img.chem.ucl.ac.uk/sgp/large/143bz1.htm

Cheers

-- Ian


On Wed, 22 Jul 2020 at 14:42, Eleanor Dodson <
176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk> wrote:

> But surely P3 symmetry ' cell ( a,a,c 90 90 120) with origin shifts
> (⅓,⅔,0), +(⅔,⅓,0) can just be indexed as P3 with
> cell (a/sqrt(3), a/sqrt(3), c, 90 90 120) ??
> Eleanor
>
> On Wed, 22 Jul 2020 at 14:32, Nicholas Keep 
> wrote:
>
>> I have an answer from Jeremy Cockcroft the author of the 'Birkbeck'
>> Tables. Actually Jeremy has been at UCL for a decade or so and they are
>> hosted from their
>>
>> Nick
>>
>> In answer to the question regarding the use of R and H for trigonal space
>> groups, the letters refer to two distinct types of lattice centring
>> symmetry operation, namely +(⅓,⅔,⅔), +(⅔,⅓,⅓) and +(⅓,⅔,0), +(⅔,⅓,0),
>> respectively. For the subset of rhombohedral space groups, the symbol R
>> should always be used.  When the alternative unit cell with a=b=c and
>> α=β=γ is chosen, this cell corresponds to a primitive Bravais lattice, but
>> the label P is not used as this would result in confusion with
>> non-rhombohedral space groups.  (The choice of symmetry operators for
>> rhombohedral space groups is wholly dependent of the choice of unit cell,
>> i.e. hexagonal versus rhombohedral, so there is no ambiguity if the unit
>> cell is specified.)
>>
>> For the non-rhombohedral space groups, it may occasionally be convenient
>> to choose a larger H-centred unit cell that is not the usual primitive P
>> one.  (The use of larger unit cells is quite common for systems that
>> undergo phase transformations as it may enable the crystallographer to keep
>> the contents of the unit cell the same in both phases.)  Note that the
>> use of an H-centred lattice switches the order of the symmetry elements in
>> these space group symbols, e.g. P312 becomes H321.
>>
>> I am not aware of any changes to this convention, which I believe has a
>> long history.  However, it is possible that the letter H has been used
>> unwittingly for other purposes.
>>
>> Jeremy Karl Cockcroft
>>
>>
>> --
>>
>> NOTE NEW PHONE NUMBER JULY 2020
>>
>> 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
>>
>> Office G54a
>>
>> Dean Email;  scid...@bbk.ac.uk
>> Dept email n.k...@mail.cryst.bbk.ac.uk
>> Telephone 020-3926-3475  (Will contact me at home if working as well as my 
>> office)
>>
>> 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&A=1
>>
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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] Question about P3, H3 and R3 space groups

[Ian Tickle]

The important take-home message in this excellent article is surely the
conclusion:

"The significant amount of programming effort and user frustration caused
by the H3 and H32 space-group symbols is a good example of how time can be
lost by not adopting long-established standards.  This is not meant to
suggest revising the PDB as this would certainly only serve to increase the
confusion.  Rather, it is a salient reminder to the entire crystallographic
methods-developer community to avoid ad-hoc approaches whenever possible.
Ever more automated systems require highly reliable components and
unambiguous semantics.  The effort spent early in ensuring reliability and
clarity is usually rewarded many times over as time passes."

... and I would add adherence to established conventions.

Cheers

-- Ian


On Wed, 22 Jul 2020 at 14:42, Gildea, Richard (DLSLtd,RAL,LSCI) <
richard.gil...@diamond.ac.uk> wrote:

> There is a useful article in Computational Crystallography Newsletter
> 2011, 2, 12-14 that gives some background into the issues surrounding the
> H3 and H32 symbols:
>
>  "Fuzzy space group symbols: H3 and H32
>
> http://www.phenix-online.org/newsletter/CCN_2011_01.pdf
>
> Cheers,
>
> Richard
>
> Dr Richard Gildea
> Data Analysis Scientist
> Tel: +441235 77 8078
>
> Diamond Light Source Ltd.
> Diamond House
> Harwell Science & Innovation Campus
> Didcot
> Oxfordshire
> OX11 0DE
> --
> *From:* CCP4 bulletin board  on behalf of David
> Vizarraga Revuelto 
> *Sent:* 22 July 2020 12:20
> *To:* CCP4BB@JISCMAIL.AC.UK 
> *Subject:* [ccp4bb] Question about P3, H3 and R3 space groups
>
> Dear all,
>
> Let me ask a question about the P3,H3, R3 space group annotations.
> I had the idea that H3 was the recommended annotation for the hexagonal
> representation of R3 (space group number 146). However, in the Birbeck
> space groups web page (attached) H3 is associated with the space group
> number 143 corresponding to P3. Similarly for all the other H groups
> assigned in the page. Moreover in the web page none of the R space groups
> is assigned to an H annotation.
>
> H3 corresponds to 143 or  to 146?
> Is there a space group 154 annotated as H32 1 2?
>
> Many thanks.
>
>
>
> "Note that the figure showing the relationship between primitive and
> R-centred rhomohedral cells with hexagonal axes is clickable
>
> Rhombohedral with Hexagonal axes
> 146. *R* 3  148. *R* -3
>  155. *R* 3 2
>  160. *R* 3 *m*
>  161. *R* 3 *c*
>  166. *R* -3 *m*
> 
> 167. *R* -3 *c* 
> H-centred Trigonal
> 143. *H* 3  144. *H* 31
>  145. *H* 32
>  147. *H* -3
>  149. *H* 3 2 1
>  150. *H* 3 1 2
> 
> 151. *H* 31 2 1  152. *H*
>  31 1 2  153. *H* 32 2 1
>  154. *H* 32 1 2
>  156. *H* 3 1 *m*
>  157. *H* 3 *m* 1
> 
> 158. *H* 3 1 *c*  159. *H*
>  3 *c* 1  162. *H* -3 *m*
>  1  163. *H* -3 *c* 1
>  164. *H* -3 1 *m*
>  165. *H* -3 1 *c*
> 
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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
> t

Re: [ccp4bb] Question about P3, H3 and R3 space groups

[Ian Tickle]

The original reference for the H cell is the very first edition of Int.
Tab.:

Hermann, C. (1935).  Internationale Tabellen zur Bestimmung von
Kristallstrukturen.  Berlin: Gebrueder Borntraeger.

Cheers

-- Ian


On Wed, 22 Jul 2020 at 17:34, Eleanor Dodson <
176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk> wrote:

> Well - yes . I am a true devotee of doctored cells to match something
> already in existence in a higher symmetry which has become approximate in
> some new manifestation! But I hadnt realised there were official versions
> of doctoring..
> Eleanor
>
> On Wed, 22 Jul 2020 at 16:29, Jeremy Karl Cockcroft 
> wrote:
>
>> Dear Eleanor,
>> What you say is absolutely spot-on! An H3 cell can be reduced down to the
>> smaller P3 cell as you pointed out.
>>
>> However, sometimes it may be useful to use a larger unit cell. I can't
>> give an example for trigonal space groups or from protein crystallography,
>> but in a recent paper, I used a unit cell in C-1 (i.e. a doubled P-1
>> triclinic cell) as this related to the C-centred monoclinic cell as
>> exhibited in a higher temperature phase. I could have used P-1, but I knew
>> that chemists would see the relationship between the phases more easily by
>> using an enlarged cell. I have done this sort of thing many times, e.g. I
>> used F2/d for the low temperature phase of DI (HI) many years ago instead
>> of C2/c as this related to the face-centred cubic form. As I am interested
>> in phase transitions, I  tabulated a range of space-group settings for
>> enlarged unit cells on my site.
>>
>> I am not sure that this will make the CCP4 list as I am not subscribed to
>> it - please feel free to echo it on there.
>> Best regards,
>> Jeremy Karl.
>> ***
>> Dr Jeremy Karl Cockcroft
>> Department of Chemistry
>> (University College London)
>> Christopher Ingold Laboratories
>> 20 Gordon Street
>> London WC1H 0AJ
>> +44 (0) 20 7679 1004 (laboratory)
>> +44 (0) 7981 875 829 (cell/mobile)
>> j.k.cockcr...@ucl.ac.uk or jeremyk...@gmail.com
>> http://img.chem.ucl.ac.uk/www/cockcroft/homepage.htm
>> ***
>> 6 Wellington Road
>> Horsham
>> West Sussex
>> RH12 1DD
>> +44 (0) 1403 256946 (home)
>> ***
>>
>>
>> On Wed, 22 Jul 2020 at 14:51, Nicholas Keep 
>> wrote:
>>
>>>
>>>
>>>
>>>  Forwarded Message 
>>> Subject: Re: [ccp4bb] Question about P3, H3 and R3 space groups
>>> Date: Wed, 22 Jul 2020 14:41:27 +0100
>>> From: Eleanor Dodson <176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk>
>>> <176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk>
>>> Reply-To: Eleanor Dodson 
>>> 
>>> To: CCP4BB@JISCMAIL.AC.UK
>>>
>>> But surely P3 symmetry ' cell ( a,a,c 90 90 120) with origin shifts
>>> (⅓,⅔,0), +(⅔,⅓,0) can just be indexed as P3 with
>>> cell (a/sqrt(3), a/sqrt(3), c, 90 90 120) ??
>>> Eleanor
>>>
>>> On Wed, 22 Jul 2020 at 14:32, Nicholas Keep 
>>> wrote:
>>>
 I have an answer from Jeremy Cockcroft the author of the 'Birkbeck'
 Tables. Actually Jeremy has been at UCL for a decade or so and they are
 hosted from their

 Nick

 In answer to the question regarding the use of R and H for trigonal
 space groups, the letters refer to two distinct types of lattice centring
 symmetry operation, namely +(⅓,⅔,⅔), +(⅔,⅓,⅓) and +(⅓,⅔,0), +(⅔,⅓,0),
 respectively. For the subset of rhombohedral space groups, the symbol R
 should always be used.  When the alternative unit cell with a=b=c and
 α=β=γ is chosen, this cell corresponds to a primitive Bravais lattice, but
 the label P is not used as this would result in confusion with
 non-rhombohedral space groups.  (The choice of symmetry operators for
 rhombohedral space groups is wholly dependent of the choice of unit cell,
 i.e. hexagonal versus rhombohedral, so there is no ambiguity if the unit
 cell is specified.)

 For the non-rhombohedral space groups, it may occasionally be
 convenient to choose a larger H-centred unit cell that is not the usual
 primitive P one.  (The use of larger unit cells is quite common for
 systems that undergo phase transformations as it may enable the
 crystallographer to keep the contents of the unit cell the same in both
 phases.)  Note that the use of an H-centred lattice switches the order
 of the symmetry elements in these space group symbols, e.g. P312 becomes
 H321.

 I am not aware of any changes to this convention, which I believe has a
 long history.  However, it is possible that the letter H has been used
 unwittingly for other purposes.

 Jeremy Karl Cockcroft


 --

 NOTE NEW PHONE NUMBER JULY 2020

 Prof Nicholas H. Keep
 Executive Dean of School of Science
 Professor of Biomolecular Science
 Crystallography, Institute for Structural and Molecular

Re: [ccp4bb] ligand bound to only one chain in the crystal

[Ian Tickle]

Hi Christian

I wouldn't worry: if the density is clear that nails it.  You didn't say
whether this is a soak or co-crystallization.  I assume the former since
you mention solvent channels.  In my experience this is much more likely in
the case of soaks, which can often (though not always) be rationalised by
the kinetic effect (different rates of exchange of bound and free ligand
due to different accessibilities), so the time to attain equilibrium can be
much longer than your soaking time, whereas in the case of
co-crystallizations it's obviously pre-equilibrated and determined purely
by the binding affinity.

Even if there are no obvious solvent channels leading from the bulk solvent
to the binding sites, a soaked ligand can still get in (particularly if
high-affinity which prevents it leaving again), because the protein can
"breathe" opening up short-lived channels which close behind the ligand.

Cheers

-- Ian


On Tue, 27 Oct 2020 at 10:29, Christian GALICIA <
christian.galicia.diaz.sant...@vub.be> wrote:

> Hello,
> In our structure only one chain in a crystallographic trimer
> (non-biological) shows a ligand bound to it (with clear density). There
> doesn't seem to be any channels (or lack of them) favoring that specific
> site. Can the community give your opinion on whether this can make the
> presence of the ligand or its biological role questionable, and give any
> examples of similar cases you might be aware of. Thank you.
> --
> *Christian Galicia*
> Post Doctoral Scientist
> E-mail: cgali...@vub.be
>
>
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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] Refmac not handling microheterogeneity?

[Ian Tickle]

Dear All

I just downloaded a PDB file (7A5V) from the EBI server, tried to run
Refmac on it and got the error:

ERROR: in chain A residue: 279 different residues have the same number
There is an error in the input coordinate file
At least one the chains has 2 residues with the same number
===> Error: Problem with coordinate file

and indeed residue A279 has:

ATOM   2354  N  ATHR A 279 138.241 168.068 154.050  0.50 27.65
 N
and
ATOM   2361  N  BLYS A 279 138.238 168.081 154.020  0.50 32.20
 N
and the same for all the other atoms in the residues.

Searching the CCP4BB archives for "microheterogeneity" I see that this has
been discussed before and apparently it should "just work" if there are alt
atom indicators (check) and occupancies add up to <= 1 (check).  I must say
I also was of the impression that it "just worked" so I'm a bit confused
now why it doesn't.

Version info:
DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
### CCP4 7.1.008: Refmac  version 5.8.0267 : 24/08/20##

Is there some other hack I need to do to get it to work?

Cheers

-- Ian



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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] Refmac not handling microheterogeneity?

[Ian Tickle]

Sorry Eleanor, same problem in 'interleaved' order (except for 2 extra
atoms in LYS).

Strangely the error message is now repeated 91 times, even though there are
only 16 atoms (7+9) in the 2 residues: previously I only got the message
once !

Guess I must have imagined that it worked - it's called 'expectation bias' !

Thanks anyway.

-- Ian


On Wed, 2 Dec 2020 at 18:34, Eleanor Dodson <
176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk> wrote:

> Only a hunch but this works:
>
> ATOM 1036 OD1AASN A 172 -7.722 13.371 -18.195 0.50 5.12 O
>
> ATOM 1037 OD1BASN A 172 -7.152 14.800 -15.791 0.50 7.63 O
>
>
> And here you have:ATOM 2354 N ATHR A 279 138.241 168.068 154.050 0.50
> 27.65 N
>
> ATOM 2355 CA ATHR A 279 136.909 167.684 153.607 0.50 28.45 C
>
> ATOM 2356 C ATHR A 279 135.937 167.731 154.799 0.50 31.92 C
>
> ATOM 2357 O ATHR A 279 136.426 167.682 155.949 0.50 32.52 O
>
> ATOM 2358 CB ATHR A 279 136.906 166.273 153.009 0.50 27.04 C
>
> ATOM 2359 OG1ATHR A 279 137.119 165.333 154.066 0.50 28.59 O
>
> ATOM 2360 CG2ATHR A 279 137.957 166.077 151.931 0.50 27.69 C
>
> ATOM 2361 N BLYS A 279 138.238 168.081 154.020 0.50 32.20 N
>
> ATOM 2362 CA BLYS A 279 136.870 167.701 153.585 0.50 36.51 C
>
> ATOM 2363 C BLYS A 279 135.930 167.793 154.787 0.50 38.18 C
>
> ATOM 2364 O BLYS A 279 136.377 168.014 155.910 0.50 42.23 O
>
> ATOM 2365 CB BLYS A 279 136.887 166.298 152.984 0.50 40.70 C
>
> ATOM 2366 CG BLYS A 279 137.909 166.091 151.872 0.50 46.05 C
>
> ATOM 2367 CD BLYS A 279 138.177 164.645 151.591 0.50 50.67 C
>
> ATOM 2368 CE BLYS A 279 139.166 164.047 152.568 0.50 59.69 C
>
> ATOM 2369 NZ BLYS A 279 140.515 163.892 151.967 0.50 59.05 N
>
>
>
>
> In case 1 OD1 A is immediately followed bu OD1B
>
>
> In second case - all As listed then all Bs
>
>
> Eleanor
>
>
>
>
> On Wed, 2 Dec 2020 at 14:34, Robbie Joosten 
> wrote:
>
>> Hi Ian,
>>
>> AFAIK there is no clean solution for this and I imagine this problem goes
>> very deep into the internal representation of the model in REFMAC. That
>> said, 1 in 6 missing PDB-REDO entries is caused by this problem, so a
>> solution would be very welcome.
>>
>> Cheers,
>> Robbie
>>
>> > -Original Message-
>> > From: CCP4 bulletin board  On Behalf Of Ian
>> > Tickle
>> > Sent: Wednesday, December 2, 2020 15:02
>> > To: CCP4BB@JISCMAIL.AC.UK
>> > Subject: [ccp4bb] Refmac not handling microheterogeneity?
>> >
>> >
>> > Dear All
>> >
>> > I just downloaded a PDB file (7A5V) from the EBI server, tried to run
>> Refmac
>> > on it and got the error:
>> >
>> > ERROR: in chain A residue: 279 different residues have the same number
>> > There is an error in the input coordinate file
>> >
>> > At least one the chains has 2 residues with the same number ===> Error:
>> > Problem with coordinate file
>> >
>> >
>> > and indeed residue A279 has:
>> >
>> > ATOM   2354  N  ATHR A 279 138.241 168.068 154.050  0.50 27.65
>>  N
>> >
>> > and
>> > ATOM   2361  N  BLYS A 279 138.238 168.081 154.020  0.50 32.20
>>  N
>> > and the same for all the other atoms in the residues.
>> >
>> > Searching the CCP4BB archives for "microheterogeneity" I see that this
>> has
>> > been discussed before and apparently it should "just work" if there are
>> alt
>> > atom indicators (check) and occupancies add up to <= 1 (check).  I must
>> say I
>> > also was of the impression that it "just worked" so I'm a bit confused
>> now
>> > why it doesn't.
>> >
>> > Version info:
>> > DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
>> > ### CCP4 7.1.008: Refmac  version 5.8.0267 : 24/08/20##
>> >
>> > Is there some other hack I need to do to get it to work?
>> >
>> > Cheers
>> >
>> > -- Ian
>> >
>> >
>> >
>> >
>> > 
>> >
>> >
>> > To unsubscribe from the CCP4BB list, click the following link:
>> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
>>
>>
>> 
>>
>> To unsubscribe from the CCP4BB list, click the following link:
>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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&A=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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] Refmac not handling microheterogeneity?

[Ian Tickle]

Hi Keitaro

Perfect!

Thanks, that's great.

Cheers

-- Ian


On Wed, 2 Dec 2020 at 22:31, Keitaro Yamashita 
wrote:

> Dear Ian,
>
> For the moment in Refmac5 we need to use insertion codes to handle
> microheterogeneity. LINKR records are also needed in the header. So
> 7a5v.pdb should be changed like this:
>
> 954a955,957
> > LINKRTHR A 279 LYS A 279A
>  gap
> > LINKRC   VAL A 278 N   LYS A 279A
>  TRANS
> > LINKRC   THR A 279 N   ALA A 280
> TRANS
> 957c960
> < CRYST11.0001.0001.000  90.00  90.00  90.00 P 1
> ---
> > CRYST1  292.212  292.212  292.212  90.00  90.00  90.00 P 1
>
> 3332,3347c3335,3350
> < ATOM   2354  N  ATHR A 279 138.241 168.068 154.050  0.50 27.65
>  N
> < ATOM   2355  CA ATHR A 279 136.909 167.684 153.607  0.50 28.45
>  C
> < ATOM   2356  C  ATHR A 279 135.937 167.731 154.799  0.50 31.92
>  C
> < ATOM   2357  O  ATHR A 279 136.426 167.682 155.949  0.50 32.52
>  O
> < ATOM   2358  CB ATHR A 279 136.906 166.273 153.009  0.50 27.04
>  C
> < ATOM   2359  OG1ATHR A 279 137.119 165.333 154.066  0.50 28.59
>  O
> < ATOM   2360  CG2ATHR A 279 137.957 166.077 151.931  0.50 27.69
>  C
> < ATOM   2361  N  BLYS A 279 138.238 168.081 154.020  0.50 32.20
>  N
> < ATOM   2362  CA BLYS A 279 136.870 167.701 153.585  0.50 36.51
>  C
> < ATOM   2363  C  BLYS A 279 135.930 167.793 154.787  0.50 38.18
>  C
> < ATOM   2364  O  BLYS A 279 136.377 168.014 155.910  0.50 42.23
>  O
> < ATOM   2365  CB BLYS A 279 136.887 166.298 152.984  0.50 40.70
>  C
> < ATOM   2366  CG BLYS A 279 137.909 166.091 151.872  0.50 46.05
>  C
> < ATOM   2367  CD BLYS A 279 138.177 164.645 151.591  0.50 50.67
>  C
> < ATOM   2368  CE BLYS A 279 139.166 164.047 152.568  0.50 59.69
>  C
> < ATOM   2369  NZ BLYS A 279 140.515 163.892 151.967  0.50 59.05
>  N
> ---
> > ATOM   2354  N   THR A 279 138.241 168.068 154.050  0.50 27.65
>  N
> > ATOM   2355  CA  THR A 279 136.909 167.684 153.607  0.50 28.45
>  C
> > ATOM   2356  C   THR A 279 135.937 167.731 154.799  0.50 31.92
>  C
> > ATOM   2357  O   THR A 279 136.426 167.682 155.949  0.50 32.52
>  O
> > ATOM   2358  CB  THR A 279 136.906 166.273 153.009  0.50 27.04
>  C
> > ATOM   2359  OG1 THR A 279 137.119 165.333 154.066  0.50 28.59
>  O
> > ATOM   2360  CG2 THR A 279 137.957 166.077 151.931  0.50 27.69
>  C
> > ATOM   2361  N   LYS A 279A138.238 168.081 154.020  0.50 32.20
>  N
> > ATOM   2362  CA  LYS A 279A136.870 167.701 153.585  0.50 36.51
>  C
> > ATOM   2363  C   LYS A 279A135.930 167.793 154.787  0.50 38.18
>  C
> > ATOM   2364  O   LYS A 279A136.377 168.014 155.910  0.50 42.23
>  O
> > ATOM   2365  CB  LYS A 279A136.887 166.298 152.984  0.50 40.70
>  C
> > ATOM   2366  CG  LYS A 279A137.909 166.091 151.872  0.50 46.05
>  C
> > ATOM   2367  CD  LYS A 279A138.177 164.645 151.591  0.50 50.67
>  C
> > ATOM   2368  CE  LYS A 279A139.166 164.047 152.568  0.50 59.69
>  C
> > ATOM   2369  NZ  LYS A 279A140.515 163.892 151.967  0.50 59.05
>  N
>
> We deposited the PDB file that could be handled by Refmac5, but
> insertion code was replaced with alt loc code in the annotation
> process.
>
> Please also note that the NCS constraint function with evaluation of
> nonbonded interactions etc will be available in the next update.
>
> Best regards,
> Keitaro
>
> On 2020/12/02 21:41, Ian Tickle wrote:
> >
> > Sorry Eleanor, same problem in 'interleaved' order (except for 2 extra
> atoms in LYS).
> >
> > Strangely the error message is now repeated 91 times, even though there
> are only 16 atoms (7+9) in the 2 residues: previously I only got the
> message once !
> >
> > Guess I must have imagined that it worked - it's called 'expectation
> bias' !
> >
> > Thanks anyway.
> >
> > -- Ian
> >
> >
> > On Wed, 2 Dec 2020 at 18:34, Eleanor Dodson <
> 176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk  176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk>> wrote:
> >
> > Only a hunch but this works:
> >
> > ATOM 1036 OD1AASN A 172 -7.722 13.371 -18.195 0.50 5.12 O
> >
> > ATOM 1037 OD1BASN A 172 -7.152 14.800 -15.791 0.50 7.63 O
> >
> >
> > And here you have:ATOM 2354 N ATHR A 2

Re: [ccp4bb] External: Re: [ccp4bb] AlphaFold: more thinking and less pipetting (?)

[Ian Tickle]

There was a little bit of press-release hype: the release stated "a score
of around 90 GDT is informally considered to be competitive with results
obtained from experimental methods" and "our latest AlphaFold system
achieves a median score of 92.4 GDT overall across all targets. This means
that our predictions have an average error (RMSD
)
of approximately 1.6 Angstroms ,".

Experimental methods achieve an average error of around 0.2 Ang. or better
at 2 Ang. resolution, and of course much better at atomic resolution (1
Ang. or better), or around 0.5 Ang. at 3 Ang. resolution.  For
ligand-binding studies I would say you need 3 Ang. resolution or better.
1.6 Ang. error is probably equivalent to around 4 Ang. resolution.  No
doubt that will improve with time and experience, though I think it will be
an uphill struggle to get better than 1 Ang. error, simply because the
method can't be better than the data that go into it and 1-1.5 Ang.
represents a typical spread of homologous models in the PDB.  So yes very
competitive if you're desperate for a MR starting model, but not quite yet
there for a refined high-resolution structure.

Cheers

-- Ian


On Tue, 8 Dec 2020 at 12:11, Harry Powell - CCP4BB <
193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote:

> Hi
>
> It’s a bit more than science by press release - they took part in CASP14
> where they were given sequences but no other experimental data, and did
> significantly better than the other homology modellers (who had access to
> the same data) when judge by independent analysis. There were things wrong
> with their structures, sure, but in almost every case they were less wrong
> than the other modellers (many of whom have been working on this problem
> for decades).
>
> It _will_ be more impressive once the methods they used (or equivalents)
> are implemented by other groups and are available to the “public” (I
> haven’t found an AlphaFold webserver to submit a sequence to, whereas the
> other groups in the field do make their methods readily available), but
> it’s still a step-change in protein structure prediction - it shows it can
> be done pretty well.
>
> Michel is right, of course; you can’t have homology modelling without
> homologous models, which are drawn from the PDB - but the other modellers
> had the same access to the PDB (just as we all do…).
>
> Just my two ha’porth.
>
> Harry
>
> > On 8 Dec 2020, at 11:33, Goldman, Adrian 
> wrote:
> >
> > My impression is that they haven’t published the code, and it is science
> by press-release.  If one of us tried it, we would - rightly - get hounded
> out of time.
> >
> > Adrian
> >
> >
> >
> >> On 4 Dec 2020, at 15:57, Michel Fodje 
> wrote:
> >>
> >> I think the results from AlphaFold2, although exciting and a
> breakthrough are being exaggerated just a bit.  We know that all the
> information required for the 3D structure is in the sequence. The protein
> folding problem is simply how to go from a sequence to the 3D structure.
> This is not a complex problem in the sense that cells solve it
> deterministically.  Thus the problem is due to lack of understanding and
> not due to complexity.  AlphaFold and all the others trying to solve this
> problem are “cheating” in that they are not just using the sequence, they
> are using other sequences like it (multiple-sequence alignments), and they
> are using all the structural information contained in the PDB.  All of this
> information is not used by the cells.   In short, unless AlphaFold2 now
> allows us to understand how exactly a single protein sequence produces a
> particular 3D structure, the protein folding problem is hardly solved in a
> theoretical sense. The only reason we know how well AlphaFold2 did is
> because the structures were solved and we could compare with the
> predictions, which means verification is lacking.
> >>
> >> The protein folding problem will be solved when we understand how to go
> from a sequence to a structure, and can verify a given structure to be
> correct without experimental data. Even if AlphaFold2 got 99% of structures
> right, your next interesting target protein might be the 1%. How would you
> know?   Until then, what AlphaFold2 is telling us right now is that all
> (most) of the information present in the sequence that determines the 3D
> structure can be gleaned in bits and pieces scattered between homologous
> sequences, multiple-sequence alignments, and other protein 3D structures in
> the PDB.  Deep Learning allows a huge amount of data to be thrown at a
> problem and the back-propagation of the networks then allows careful
> fine-tuning of weights which determine how relevant different pieces of
> information are to the prediction.  The networks used here are humongous
> and a detailed look at the weights (if at all feasible) may point us in the
> right direction.
> >>
> >>
> >> From: CCP4 b

Re: [ccp4bb] External: Re: [ccp4bb] AlphaFold: more thinking and less pipetting (?)

[Ian Tickle]

Hi Tristan,

Point taken: unobserved parts of the structure have a very large (if not
undefined) experimental error!

I'd be interested to see how that average 1.6 Ang. error is distributed in
space: presumably that data is in the CASP analysis somewhere.

Cheers

-- Ian


On Tue, 8 Dec 2020 at 13:25, Tristan Croll  wrote:

> This is a number that needs to be interpreted with some care. 2 Å crystal
> structures in general achieve an RMSD of 0.2 Å on the portion of the
> crystal that's resolved, including loops that are often only in
> well-resolved conformations due to physiologically-irrelevant crystal
> packing interactions. The predicted models, on the other hand, are in
> isolation. Once you get to the level achieved by this last round of
> predictions, that starts making fair comparison somewhat more difficult*.
> Two obvious options that I see: (1) limit the comparison only to the stable
> core of the protein (in which case many of the predictions have RMSDs in
> the very low fractions of an Angstrom), or (2) compare ensembles derived
> from MD simulations starting from the experimental and predicted structure,
> and see how well they overlap.
>
> -- Tristan
>
> * There's one more thorny issue when you get to this level: it becomes
> more and more possible (even likely) that the prediction gets some things
> right that are wrong in the experimental structure.
> --------------
> *From:* CCP4 bulletin board  on behalf of Ian
> Tickle 
> *Sent:* 08 December 2020 13:04
> *To:* CCP4BB@JISCMAIL.AC.UK 
> *Subject:* Re: [ccp4bb] External: Re: [ccp4bb] AlphaFold: more thinking
> and less pipetting (?)
>
>
> There was a little bit of press-release hype: the release stated "a score
> of around 90 GDT is informally considered to be competitive with results
> obtained from experimental methods" and "our latest AlphaFold system
> achieves a median score of 92.4 GDT overall across all targets. This means
> that our predictions have an average error (RMSD
> <https://en.wikipedia.org/wiki/Root-mean-square_deviation_of_atomic_positions>)
> of approximately 1.6 Angstroms <https://en.wikipedia.org/wiki/Angstrom>,".
>
> Experimental methods achieve an average error of around 0.2 Ang. or better
> at 2 Ang. resolution, and of course much better at atomic resolution (1
> Ang. or better), or around 0.5 Ang. at 3 Ang. resolution.  For
> ligand-binding studies I would say you need 3 Ang. resolution or better.
> 1.6 Ang. error is probably equivalent to around 4 Ang. resolution.  No
> doubt that will improve with time and experience, though I think it will be
> an uphill struggle to get better than 1 Ang. error, simply because the
> method can't be better than the data that go into it and 1-1.5 Ang.
> represents a typical spread of homologous models in the PDB.  So yes very
> competitive if you're desperate for a MR starting model, but not quite yet
> there for a refined high-resolution structure.
>
> Cheers
>
> -- Ian
>
>
> On Tue, 8 Dec 2020 at 12:11, Harry Powell - CCP4BB <
> 193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote:
>
> Hi
>
> It’s a bit more than science by press release - they took part in CASP14
> where they were given sequences but no other experimental data, and did
> significantly better than the other homology modellers (who had access to
> the same data) when judge by independent analysis. There were things wrong
> with their structures, sure, but in almost every case they were less wrong
> than the other modellers (many of whom have been working on this problem
> for decades).
>
> It _will_ be more impressive once the methods they used (or equivalents)
> are implemented by other groups and are available to the “public” (I
> haven’t found an AlphaFold webserver to submit a sequence to, whereas the
> other groups in the field do make their methods readily available), but
> it’s still a step-change in protein structure prediction - it shows it can
> be done pretty well.
>
> Michel is right, of course; you can’t have homology modelling without
> homologous models, which are drawn from the PDB - but the other modellers
> had the same access to the PDB (just as we all do…).
>
> Just my two ha’porth.
>
> Harry
>
> > On 8 Dec 2020, at 11:33, Goldman, Adrian 
> wrote:
> >
> > My impression is that they haven’t published the code, and it is science
> by press-release.  If one of us tried it, we would - rightly - get hounded
> out of time.
> >
> > Adrian
> >
> >
> >
> >> On 4 Dec 2020, at 15:57, Michel Fodje 
> wrote:
> >>
> >> I think the results from AlphaFold2, although exciting and a
> breakthrough are bein

Re: [ccp4bb] External: Re: [ccp4bb] AlphaFold: more thinking and less pipetting (?)

[Ian Tickle]

Hi Marko

I hope he hasn't confused resolution with RMSD error:

"Just keep in mind that (1) a lower RMSD represents a better predicted
structure, and that (2) most experimental structures have a resolution
around 2.5 Å. Taking this into consideration, about a third (36%) of Group
427’s submitted targets were predicted with a root-mean-square deviation
(RMSD) under 2 Å, and 86% were under 5 Å, with a total mean of 3.8 Å."

Cheers

-- Ian



On Tue, 8 Dec 2020 at 13:51, Marko Hyvonen  wrote:

> Here is another take on this topic, by Carlos Quteiral (@c_outeiral), from
> a non-crystallographer's point of view, covering many of the points discussed
> in this thread  (incl. an example of the model guiding correction of the
> experimental structure).
>
>
> https://www.blopig.com/blog/2020/12/casp14-what-google-deepminds-alphafold-2-really-achieved-and-what-it-means-for-protein-folding-biology-and-bioinformatics/
>
> Marko
>
> On 08/12/2020 13:25, Tristan Croll wrote:
>
> This is a number that needs to be interpreted with some care. 2 Å crystal
> structures in general achieve an RMSD of 0.2 Å on the portion of the
> crystal that's resolved, including loops that are often only in
> well-resolved conformations due to physiologically-irrelevant crystal
> packing interactions. The predicted models, on the other hand, are in
> isolation. Once you get to the level achieved by this last round of
> predictions, that starts making fair comparison somewhat more difficult*.
> Two obvious options that I see: (1) limit the comparison only to the stable
> core of the protein (in which case many of the predictions have RMSDs in
> the very low fractions of an Angstrom), or (2) compare ensembles derived
> from MD simulations starting from the experimental and predicted structure,
> and see how well they overlap.
>
> -- Tristan
>
> * There's one more thorny issue when you get to this level: it becomes
> more and more possible (even likely) that the prediction gets some things
> right that are wrong in the experimental structure.
> --
> *From:* CCP4 bulletin board 
>  on behalf of Ian Tickle 
> 
> *Sent:* 08 December 2020 13:04
> *To:* CCP4BB@JISCMAIL.AC.UK 
> 
> *Subject:* Re: [ccp4bb] External: Re: [ccp4bb] AlphaFold: more thinking
> and less pipetting (?)
>
>
> There was a little bit of press-release hype: the release stated "a score
> of around 90 GDT is informally considered to be competitive with results
> obtained from experimental methods" and "our latest AlphaFold system
> achieves a median score of 92.4 GDT overall across all targets. This means
> that our predictions have an average error (RMSD
> <https://en.wikipedia.org/wiki/Root-mean-square_deviation_of_atomic_positions>)
> of approximately 1.6 Angstroms <https://en.wikipedia.org/wiki/Angstrom>,".
>
> Experimental methods achieve an average error of around 0.2 Ang. or better
> at 2 Ang. resolution, and of course much better at atomic resolution (1
> Ang. or better), or around 0.5 Ang. at 3 Ang. resolution.  For
> ligand-binding studies I would say you need 3 Ang. resolution or better.
> 1.6 Ang. error is probably equivalent to around 4 Ang. resolution.  No
> doubt that will improve with time and experience, though I think it will be
> an uphill struggle to get better than 1 Ang. error, simply because the
> method can't be better than the data that go into it and 1-1.5 Ang.
> represents a typical spread of homologous models in the PDB.  So yes very
> competitive if you're desperate for a MR starting model, but not quite yet
> there for a refined high-resolution structure.
>
> Cheers
>
> -- Ian
>
>
> On Tue, 8 Dec 2020 at 12:11, Harry Powell - CCP4BB <
> 193323b1e616-dmarc-requ...@jiscmail.ac.uk> wrote:
>
> Hi
>
> It’s a bit more than science by press release - they took part in CASP14
> where they were given sequences but no other experimental data, and did
> significantly better than the other homology modellers (who had access to
> the same data) when judge by independent analysis. There were things wrong
> with their structures, sure, but in almost every case they were less wrong
> than the other modellers (many of whom have been working on this problem
> for decades).
>
> It _will_ be more impressive once the methods they used (or equivalents)
> are implemented by other groups and are available to the “public” (I
> haven’t found an AlphaFold webserver to submit a sequence to, whereas the
> other groups in the field do make their methods readily available), but
> it’s still a step-change in protein structure prediction - it shows it can
> be done pretty well.
>
> Michel is right, of course; you can

Re: [ccp4bb] Anomalous signal to noise details

[Ian Tickle]

Conventionally (e.g. in cryo-EM) the SNR is taken as a ratio of averages,
either the ratio of the variance of the signal (average of signal squared)
to the variance of the noise, i.e. var(signal) / var(noise), or the square
root of that, i.e. sd(signal) / sd(noise).  See here:
https://en.wikipedia.org/wiki/Signal-to-noise_ratio .

Alternatively, it may be defined as the ratio of the mean value of the
signal to its standard error, i.e. mean(signal) / sd(noise):
https://en.wikipedia.org/wiki/Signal-to-noise_ratio_(imagi
ng) <https://en.wikipedia.org/wiki/Signal-to-noise_ratio_(imaging)> , so
again a ratio of averages.  Whenever you read about SNR you have to check
carefully which of the three definitions is in use (and often it's not
stated!).

I think the confusion of ratio-of-averages vs. average-of-ratios has arisen
because in crystallography we're not actually talking about the SNR, rather
we're talking about the _average_ SNR, where the average is taken over
samples of a population that have _different_ distributions in reciprocal
space, whereas in the previous case the samples are taken from a population
whose samples are assumed to have the _same_ distribution (and therefore
same s.d.).  Note that the ratio-of-average and average-of-ratio cases
converge if all samples are drawn from the same population with uniform
distribution and s.d..

So then in our situation it is indeed correct to say that average SNR =
average( I / sd(I) ), i.e. an average of the ratios of averages!  When we
measure an _individual_ intensity with its s.d., we are already taking
averages, but they are averages over time where the standard error is
constant.  Then, when we take the spatial average SNR over different
intensities the sampling distribution and its s.d. naturally varies so we
must take the average of ratios.

Cheers

-- Ian


On Fri, 18 Dec 2020 at 20:14, Bernhard Rupp 
wrote:

> > I don't know the justification; maybe just experience? Surely the higher
> the better.  I've seen George Sheldrick deriving the value of ~0.8 when
> there is _no_ anom signal but I forgot the details, sorry ...
>
> It is derived from the mean absolute error (cf. p414 in Chapter 8 of BMC,
> with help of Ian Tickle), and holds for unmerged data. A reasonable good
> indication where to set the cutoff in practice is to look at the site vs
> occupancy plot. A distinct drop after a few good sites is usually a good
> sign, and that tends to cluster around the ~1.3 ratio.
>
>
> http://www.ruppweb.org/Garland/gallery/Ch10/pages/Biomolecular_Crystallography_Fig_10-30_PART2.htm
>
> The noise level is actually observable in data without anomalous signal
>
>
> http://www.ruppweb.org/Garland/gallery/Ch10/pages/Biomolecular_Crystallography_Fig_10-29.htm
>
> Best BR
>
>
>
>
>
> best wishes,
>
> Kay
>
> >
> >Thanks!
> >-- David
> >
> >###
> >#
> >
> >To unsubscribe from the CCP4BB list, click the following link:
> >https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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&A=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&A=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&A=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] {developers] SG 18 problem cif2mtz legacy issue

[Ian Tickle]

Hi  Bernhard

I gave up trying to use CIF2MTZ in the STARANISO server over a year ago.  I
agree with Marcin that his GEMMI program is the way to go.  It does
everything you need and Marcin is very quick to respond to any issues.

The problem is that there are alternate settings in the PDB so the software
just has to be able to handle them.  The space group number should not be
used for anything other than information, for the obvious reason that it's
not unique.  AFAIK all software uses either the full H-M symbol or the
general equivalent positions themselves (e.g. Shel-X).

>From your description the axes in the SG symbol have been permuted but the
cell axes remain in the original order?  If so that's plainly a bug which
should be fixed (or CIF2MTZ put in retirement).

Cheers

-- Ian


On Wed, 6 Jan 2021 at 19:38, Bernhard Rupp  wrote:

> Dear Developers,
>
>
>
> running cif2mtz in ccp4i (or from the console) in the case of non-standard
> settings of space group 18 (which should be discouraged, to phrase it
> mildly)
>
> on the mmcif from the PDB
>
> _symmetry.space_group_name_H-M   "P 21 2 21" ß
>
> _symmetry.Int_Tables_number  18
>
> #
>
>
>
> leads to a problem because the resulting mtz file has the standard 18
> symbol
>
>
>
> Type  Merged MTZ
>
> Space group   P 21 21 2 ß
>
> Space group confidenceX  (confidence flag is not set)
>
> Cell 88.578  44.416  71.56490  90  90
>
>
>
> Not sure if this is a loss of information when generating the mmcif upon
> submission,
>
> or the SG is retrieved solely by SG number not symbol (the latter can give
> rise to a few more such situations).
>
>
>
> Best, BR
>
>
>
> --
>
> Bernhard Rupp
>
> http://www.hofkristallamt.org/
>
> b...@hofkristallamt.org
>
> +1 925 209 7429
>
> +43 676 571 0536
>
> --
>
> Many plausible ideas vanish
>
> at the presence of thought
>
> --
>
>
>
> --
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=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 cycles in refmac

[Ian Tickle]

Frank,

Point #1 - fair point;  the reason Rfree is popular, though, is because it
> is a *relative* metric, i.e. by now we have a sense of what "good" is.  So
> I predict an uphill fight for LLfree.
>

Why? I don't see any difference.  As you say Rfree is a relative metric so
your sense of what 'good' is relies on comparisons with other Rfrees (i.e.
it can only be 'better' or 'worse' not 'good' or 'bad'), but then the same
is true of LLfree (note that they both assume that exactly the same data
were used and that only the model has changed).  So when choosing between
alternative model parameterisations in order to minimise over-fitting we
compare their Rfrees and choose the lower one - same with LLfree, or we
compare the observed Rfree with the expected Rfree based on Rwork and the
obs/param ratio to check for problems with the model - same with LLfree.  In
fact you can do it better because the observations in LLfree are weighted in
exactly the same way as those in the target function.


> Point #2 would hold if we routinely let our refinements run to
> convergence;  seems common though to run "10 cycles" or "50 cycles" instead
> and draw conclusions from the behaviour of the metrics.  Are the conclusions
> really much different from the comparison-at-convergence you advocate?
> Which is in practice often less convenient.
>
> You might do 10 cycles for a quick optimisation of the coordinates, but
then I wouldn't place much faith in the R factors!  How can you draw any
conclusions from their behaviour: there's no way of predicting how they will
change in further cycles, the only way to find out is to do it.  I'm not
saying that you need to refine exhaustively on every run, that would be
silly since you don't need to know the correct value of the R  factors for
every run; but certainly on the final run before PDB submission I would
regard stopping the refinement early based on Rfree as implied in Tim's
original posting as something akin to 'cheating'.

Cheers

-- Ian

Re: [ccp4bb] number of cycles in refmac

[Ian Tickle]

Hi AR

Please define what you mean by 'over-refinement' as it's not a term I use:
does it mean 'convergence', or 'over-fitting', or 'over-optimisation'
(whatever that means) or something else?

If by "LLG is stabilized" you mean it has converged then I agree that's a
possible stopping criterion, but then so must all the refinement indicators
including R and Rfree (& RMSDs etc) since by definition at convergence there
can be no further significant changes in the parameters to cause R and Rfree
to change further.  You say R & Rfree "are going in opposite directions"
when LLG has stabilized.  It's not possible for R and Rfree to continue to
change if the refinement has converged, since that clearly implies that it
hasn't converged.

Cheers

-- Ian

PS 3 copies of your email is 2 too many (or if this is the list server
acting up again, my apologies).


On Fri, Aug 26, 2011 at 3:55 PM, protein chemistry <
proteinchemistr...@gmail.com> wrote:

> Dear Dr Ian
>
> from your argument i could not understand how many cycles to refine before
> submitting the coordinates to the PDB. what is the upper limit 100 or
> thousand or million according to my understanding, its more logical to
> stop the refinement when over refinement is  taking place (when R and Rfree
> are going in opposite directions and LLG is stabilized )
>
>
> On Fri, Aug 26, 2011 at 4:01 PM, Ian Tickle  wrote:
>
>> Frank,
>>
>> Point #1 - fair point;  the reason Rfree is popular, though, is because it
>>> is a *relative* metric, i.e. by now we have a sense of what "good" is.
>>> So I predict an uphill fight for LLfree.
>>>
>>
>> Why? I don't see any difference.  As you say Rfree is a relative metric so
>> your sense of what 'good' is relies on comparisons with other Rfrees (i.e.
>> it can only be 'better' or 'worse' not 'good' or 'bad'), but then the same
>> is true of LLfree (note that they both assume that exactly the same data
>> were used and that only the model has changed).  So when choosing between
>> alternative model parameterisations in order to minimise over-fitting we
>> compare their Rfrees and choose the lower one - same with LLfree, or we
>> compare the observed Rfree with the expected Rfree based on Rwork and the
>> obs/param ratio to check for problems with the model - same with LLfree.  In
>> fact you can do it better because the observations in LLfree are weighted in
>> exactly the same way as those in the target function.
>>
>>
>>> Point #2 would hold if we routinely let our refinements run to
>>> convergence;  seems common though to run "10 cycles" or "50 cycles" instead
>>> and draw conclusions from the behaviour of the metrics.  Are the conclusions
>>> really much different from the comparison-at-convergence you advocate?
>>> Which is in practice often less convenient.
>>>
>>> You might do 10 cycles for a quick optimisation of the coordinates, but
>> then I wouldn't place much faith in the R factors!  How can you draw any
>> conclusions from their behaviour: there's no way of predicting how they will
>> change in further cycles, the only way to find out is to do it.  I'm not
>> saying that you need to refine exhaustively on every run, that would be
>> silly since you don't need to know the correct value of the R  factors for
>> every run; but certainly on the final run before PDB submission I would
>> regard stopping the refinement early based on Rfree as implied in Tim's
>> original posting as something akin to 'cheating'.
>>
>> Cheers
>>
>> -- Ian
>>
>
>

Re: [ccp4bb] Windows 7 and Xtal Software

[Ian Tickle]

On Mon, Aug 29, 2011 at 7:53 AM, Nat Echols wrote:

> On Sun, Aug 28, 2011 at 7:23 PM, Jacob Keller <
> j-kell...@fsm.northwestern.edu> wrote:
>
>> are there any additional problems or known issues running ccp4 or
>> other xtal software on windows 7 (beyond those of Vista, etc.?)
>
>
> Phenix, ARP/wARP, and HKL2000 do not run on Windows.  I'm pretty sure none
> of Global Phasing's software does either (aside from web interfaces).
>
> -Nat
>

Correct, and you can add XDS to the list.  Also a number of data processing
utilities such as adxv & xds-viewer are only available for Linux/OSX (though
iMosflm which is on Windows could be used instead).

Cheers

-- Ian

Re: [ccp4bb] Self-rotation Patterson maps

[Ian Tickle]

Hi John,

There's some by now fairly ancient tutorial material on the SRF (though of
course the theory hasn't changed) here:

http://www.ccp4.ac.uk/dist/ccp4i/help/modules/appendices/mr-bathtutorial/mrbath2.html#section2.8

(and the following section 2.9) and here:

http://www.ccp4.ac.uk/dist/ccp4i/help/modules/appendices/mr-bathtutorial/mrbath5.html

(see section 5.2).

Cheers

-- Ian

On Mon, Aug 29, 2011 at 7:12 AM, john peter  wrote:

> Hello,
>
>  I wish to learn about self-rotation Patterson maps such as how to
> interpret a map and find out non-crystallographic symmetry. Could you
> suggest some good papers (for dummies), web-sites etc.
>
> Thanks a lot for your help.
>
> John
>

Re: [ccp4bb] ALMN

[Ian Tickle]

Hi Rex

I would assume it's the RMS deviation of the rotation function value from
the mean.  If so then it's defined in the same way as the "population
standard deviation" as given here:
http://en.wikipedia.org/wiki/Standard_deviation

Cheers

-- Ian

On Fri, Sep 9, 2011 at 4:20 PM, REX PALMER wrote:

> Dear CCP4'ers
>
> In the input instructions for ALMN it says:
> FIND peak maxpek [RMS] [OUTPUT filename]
> Read peak threshold and maximum number of peaks. MAXPEK is the maximum
> number of peaks to find (default = 20). Up to MAXPEK peaks above PEAK will
> be found, and all symmetry related peaks generated.
> If the keyword RMS is present, then the peak threshold is PEAK * RMS
> density, otherwise PEAK is the absolute threshold in the scaled map.
> Question: RMS density of what and what is the formula used?
>
> Rex Palmer
> http://www.bbk.ac.uk/biology/our-staff/emeritus-staff
> http://rexpalmer2010.homestead.com
>

Re: [ccp4bb] ALMN

[Ian Tickle]

Rex, sorry, addendum to my last post: the grid points in the Eulerian space
of the cross-RF (which is what I assume you're talking about) do not occupy
equal volumes in angular space as they would do in a Euclidean space (e.g. a
normal electron density map).  For example the volume of any grid point on
the beta=0 & 180 sections is zero (these sections actually each consist of a
line of points, and a line of course occupies no volume).  Therefore it's
necessary to weight the values in both the mean and the RMSD by the volume
of each grid point (= sin(beta)).  Whether ALMN actually does this or not
would require an examination of the source code, though it's probably
quicker to ask Eleanor!

Cheers

-- Ian

On Fri, Sep 9, 2011 at 5:26 PM, Ian Tickle  wrote:

>
> Hi Rex
>
> I would assume it's the RMS deviation of the rotation function value from
> the mean.  If so then it's defined in the same way as the "population
> standard deviation" as given here:
> http://en.wikipedia.org/wiki/Standard_deviation
>
> Cheers
>
> -- Ian
>
>
> On Fri, Sep 9, 2011 at 4:20 PM, REX PALMER wrote:
>
>> Dear CCP4'ers
>>
>> In the input instructions for ALMN it says:
>> FIND peak maxpek [RMS] [OUTPUT filename]
>> Read peak threshold and maximum number of peaks. MAXPEK is the maximum
>> number of peaks to find (default = 20). Up to MAXPEK peaks above PEAK will
>> be found, and all symmetry related peaks generated.
>> If the keyword RMS is present, then the peak threshold is PEAK * RMS
>> density, otherwise PEAK is the absolute threshold in the scaled map.
>> Question: RMS density of what and what is the formula used?
>>
>> Rex Palmer
>> http://www.bbk.ac.uk/biology/our-staff/emeritus-staff
>> http://rexpalmer2010.homestead.com
>>
>
>

Re: [ccp4bb] DNA cif files

[Ian Tickle]

Hi, it depends what you mean by 'different'.  The SUs of the new set are
much lower than the old values (0.8 deg vs. 3.0) so one would assume that
these are improved estimates based on new data.  The difference between the
old and the new is (108.4 - 107.8) = 0.6 deg with a SU of the difference of
sqrt(3^2 + 0.8^2) = 3.1 deg, so difference/SU = 0.6/3.1 = 0.2 sigma - hardly
what one could call 'significantly different'.

Cheers

-- Ian

On Fri, Sep 16, 2011 at 4:26 PM, Gregory Bowman  wrote:

> I have a question about the bond angle restraints in the DNA cif files. I
> recently submitted a protein-DNA complex to the PDB, and found out that many
> of the glycosidic bond angles (atoms O4'-C1'-N9/N1) were outside the
> accepted range. I switched from CCP4 6.1.13 to 6.2.0 (installed/updated with
> fink on Mac OSX 10.6.8), and this "fixed" the problem in that now there is a
> narrower distribution of bond angles, but the target/ideal values are
> different in these two CCP4 monomer libraries (108.4 versus 107.8):
>
> =
> /sw64/lib/*ccp4-6.1.13*/data/monomers
>
> file=a/AD.cif
> Ad   A   'Adenosine   ' DNA32
>  21 .
> Ad   N9 C1*O4* 108.4003.000
>
> file=c/CD.cif
> Cd   C   'Cytidine' DNA30
>  19 .
> Cd   N1 C1*O4* 108.4003.000
>
> file=g/GD.cif
> Gd   G   'Guanosine   ' DNA33
>  22 .
> Gd   N9 C1*O4* 108.4003.000
>
> file=t/TD.cif
> Td   T   'Thymidine   ' DNA32
>  20 .
> Td   N1 C1*O4* 108.4003.000
>
> =
> /sw64/lib/*ccp4-6.2.0*/data/monomers
>
> file=d/DA.cif
> DA   DA  '2'-DEOXYADENOSINE-5'-MONOPHOSPHATE  ' DNA34
>  22 .
> DA   "O4'"  "C1'"  N9  107.8000.800
>
> file=d/DC.cif
> DC   DC  '2'-DEOXYCYTIDINE-5'-MONOPHOSPHATE   ' DNA32
>  20 .
> DC   "O4'"  "C1'"  N1  107.8000.800
>
> file=d/DG.cif
> DG   DG  '2'-DEOXYGUANOSINE-5'-MONOPHOSPHATE  ' DNA35
>  23 .
> DG   "O4'"  "C1'"  N9  107.8000.800
>
> file=d/DT.cif
> DT   DT  'THYMIDINE-5'-MONOPHOSPHATE  ' DNA34
>  21 .
> DT   "O4'"  "C1'"  N1  107.8000.800
>
>
> Why are these values different in the two libraries? Am I looking at the
> wrong files or the wrong bonds?
>
> Thanks!
> Greg
>
>
>
>

Re: [ccp4bb] Calculate real-space R-factor/corr coeff for ligand

[Ian Tickle]

On Tue, Oct 4, 2011 at 11:21 AM, Adam Ralph  wrote:

> Dear Brigitte,
>
>
>  Looking at the formulae it could be possible to get those results.
> Take an example
> below
>
>
> Rho_cal = -0.11, 0.0, 0.05, 0.05
> Rho_obs = -0.08, 0.01, 0.04, 0.04
>
>
> R-fac = 0.02/0.0   =   undefined
>
>
> Correl =  0.0032 - (-0.0025*0.0025)
>-- = 0.99
> sqrt(0.0043 * 0.0024)
>
> Did the calculations quickly so hope they are OK. However, I designed the
> data so
> that the denominator in the R-fac is zero i.e. the sum of Rho_cal = - sum
> of Rho_obs.
> It would imply that the ATMMAP from sfall does not cover the correct set of
> grid points
> for the ligand. You expect the Fc map to be positive in this region. You
> need to generate
> a new ATMMAP for each different ligand conformation.
>
> Adam
>
>
Hi Adam

That doesn't look right to me, the formula according to Jones et al is:

 RSR = sum(| rho_obs - rho_calc |) / sum(| rho_obs +
rho_calc |)

So for your example we have RSR = (.03 + .01 + .01 + .01) / (.19 + .01 + .09
+ .09) = .13 which is obviously quite a reasonable number.

If you want some numbers which will cause a zero divide you have to make
rho_obs = - rho_calc for every point so each term in the sum in the
denominator above is zero, and therefore obviously the denominator itself
would be zero.

Here are the relevant code snippets from OVERLAPMAP:

 iave(j,i)=0
 xave(j,i)=0.
 yave(j,i)=0.

 iave(jj,ii)=iave(jj,ii)+1
 xave(jj,ii)=xave(jj,ii)+xwork
 yave(jj,ii)=yave(jj,ii)+ywork

 xave(jj,ii)=xave(jj,ii)/iave(jj,ii)
 yave(jj,ii)=yave(jj,ii)/iave(jj,ii)

 rfac(jj,ii) =  (abs(xave(jj,ii)- yave(jj,ii))) /
(abs(xave(jj,ii)+ yave(jj,ii)))

This looks wrong to me since the absolute value is being taken after the
summation instead of before, i.e. it should be forming sums of
abs(xwork-ywork) and abs(xwork+ywork).  The absolute value of a sum is not
the same as the sum of absoiute values!  Note that the division throughout
by the no of points (iave(jj,ii)) has no effect on the result.

I didn't check the formula for the correlation coefficient.

But your broad conclusion (that the data is garbage) is very probably
correct!

Cheers

-- Ian

Re: [ccp4bb] Calculate real-space R-factor/corr coeff for ligand

[Ian Tickle]

Ooops (.03+.01+.01+.01)/(.19+.01+.09+.09) = .16

-- Ian

On Tue, Oct 4, 2011 at 12:22 PM, Ian Tickle  wrote:

> On Tue, Oct 4, 2011 at 11:21 AM, Adam Ralph  wrote:
>
>> Dear Brigitte,
>>
>>
>>  Looking at the formulae it could be possible to get those results.
>> Take an example
>> below
>>
>>
>> Rho_cal = -0.11, 0.0, 0.05, 0.05
>> Rho_obs = -0.08, 0.01, 0.04, 0.04
>>
>>
>> R-fac = 0.02/0.0   =   undefined
>>
>>
>> Correl =  0.0032 - (-0.0025*0.0025)
>>-- = 0.99
>> sqrt(0.0043 * 0.0024)
>>
>> Did the calculations quickly so hope they are OK. However, I designed the
>> data so
>> that the denominator in the R-fac is zero i.e. the sum of Rho_cal = - sum
>> of Rho_obs.
>> It would imply that the ATMMAP from sfall does not cover the correct set
>> of grid points
>> for the ligand. You expect the Fc map to be positive in this region. You
>> need to generate
>> a new ATMMAP for each different ligand conformation.
>>
>> Adam
>>
>>
> Hi Adam
>
> That doesn't look right to me, the formula according to Jones et al is:
>
>  RSR = sum(| rho_obs - rho_calc |) / sum(| rho_obs +
> rho_calc |)
>
> So for your example we have RSR = (.03 + .01 + .01 + .01) / (.19 + .01 +
> .09 + .09) = .13 which is obviously quite a reasonable number.
>
> If you want some numbers which will cause a zero divide you have to make
> rho_obs = - rho_calc for every point so each term in the sum in the
> denominator above is zero, and therefore obviously the denominator itself
> would be zero.
>
> Here are the relevant code snippets from OVERLAPMAP:
>
>  iave(j,i)=0
>  xave(j,i)=0.
>  yave(j,i)=0.
>
>  iave(jj,ii)=iave(jj,ii)+1
>  xave(jj,ii)=xave(jj,ii)+xwork
>  yave(jj,ii)=yave(jj,ii)+ywork
>
>  xave(jj,ii)=xave(jj,ii)/iave(jj,ii)
>  yave(jj,ii)=yave(jj,ii)/iave(jj,ii)
>
>  rfac(jj,ii) =  (abs(xave(jj,ii)- yave(jj,ii))) /
> (abs(xave(jj,ii)+ yave(jj,ii)))
>
> This looks wrong to me since the absolute value is being taken after the
> summation instead of before, i.e. it should be forming sums of
> abs(xwork-ywork) and abs(xwork+ywork).  The absolute value of a sum is not
> the same as the sum of absoiute values!  Note that the division throughout
> by the no of points (iave(jj,ii)) has no effect on the result.
>
> I didn't check the formula for the correlation coefficient.
>
> But your broad conclusion (that the data is garbage) is very probably
> correct!
>
> Cheers
>
> -- Ian
>

Re: [ccp4bb] How to get formfactor for Zn +2.

[Ian Tickle]

On Tue, Oct 4, 2011 at 4:41 PM, Eleanor Dodson  wrote:

> OK
>
> So the ATOM TYPE has ZN O C S etc in column 77/78 and the +2 etc in 79/80
>
> Is there any documentation for this?
>
> E


Yes, see:
ftp://ftp.wwpdb.org/pub/pdb/doc/format_descriptions/Format_v33_A4.pdf

Though this has been the format for ATOM/HETATM records ever since I can
remember.

Cheers

-- Ian

Re: [ccp4bb] Calculate real-space R-factor/corr coeff for ligand

[Ian Tickle]

On Tue, Oct 4, 2011 at 7:14 PM,  wrote:

> Hi Adam and Ian,
>
> Thanks for your help.  If I re-calculate the R-factors with the correct
> absolute values I get more reasonable values.  However, I'm still a bit
> confused because the output given by the Overlapmap program is structure
> factor values, which are used to calculate the real-space R-factors.  Should
> this not be Rho values instead?  Additionally, a lot of my structure
> factors, even for the protein, which I know fits well within the
> experimental density, are 0 for the sidechains or negative.  Any idea what's
> going on here?  I've attached some sample data from the Overlapmap output
> file.  Thanks in advance.
>
> Brigitte
>
>
>

Hi Brigitte

Yes I agree with you that the output is very confusing!  I don't know
exactly what 'Fobs' & 'Fcalc' are but I'm pretty sure they can't be
structure factors.  I would guess that 'F' is actually rho (i.e. rho
calculated by FFT from F).  According to the man page overlapmap only inputs
& outputs maps: nowhere does it mention reading or writing SFs.  Very
confusing!

Also why the values are small or negative, I've no idea as I've never used
overlapmap.  I would keep posting to the BB in the hope that someone can
solve your problem.

Cheers

-- Ian

Re: [ccp4bb] Overlapmap

[Ian Tickle]

On Wed, Oct 5, 2011 at 11:03 AM, Adam Ralph  wrote:

> Hi Brigitte,
>You are correct, the columns labeled Fobs and Fcal refer to density. The
> columns should be: averaged density for Obs and Cal for the main chain, then
> averaged density Obs and Cal for the side chains. I have included a version
> of overlapmap that calculates the R-factor correctly and have changed the
> above columns in the output.
> All the best Adam
>

Documentation should be fixed too :)

-- Ian

Re: [ccp4bb] Overlapmap

[Ian Tickle]

Adam, sorry I don't use overlapmap, for the reasons you mention (and many
others!).  In fact I decided it was in such a mess that it was irrecoverable
& so I wrote my own program EDSTATS to do all all these electron density
stats (and more).  I talked about it at the last CSW (
http://www.cse.scitech.ac.uk/events/CCP4_2011/talks/tickle.pdf), and
submitted it to CCP4 in January but it doesn't seem to have made the latest
release yet (or even the pre-release), so at the moment I'm just
distributing it to anyone who's interested.

Cheers

-- Ian

On Wed, Oct 5, 2011 at 12:31 PM, Adam Ralph wrote:

> Hi Ian,
>
>  Yes I agree. The whole program is a bit of a mess and could do with some
> updating.
> I am not an official CCP4 maintainer any more but I might send them
> something. Do you
> know how to use SFALL ATMMAP? I tired to test overlapmap's residue
> correlation but did
> not work properly.
>
> Adam
>
>
>
> - Original Message -
> From: "Ian Tickle" 
> To: "Adam Ralph" 
> Cc: CCP4BB@jiscmail.ac.uk
> Sent: Wednesday, 5 October, 2011 11:36:30 AM
> Subject: Re: [ccp4bb] Overlapmap
>
>
>
> On Wed, Oct 5, 2011 at 11:03 AM, Adam Ralph < adam.ra...@nuim.ie > wrote:
>
>
>
> Hi Brigitte,
> You are correct, the columns labeled Fobs and Fcal refer to density. The
> columns should be: averaged density for Obs and Cal for the main chain, then
> averaged density Obs and Cal for the side chains. I have included a version
> of overlapmap that calculates the R-factor correctly and have changed the
> above columns in the output.
> All the best Adam
>
> Documentation should be fixed too :)
>
> -- Ian
>

Re: [ccp4bb] change of origin for reflections or map

[Ian Tickle]

On Wed, Oct 12, 2011 at 1:35 AM, James Holton  wrote:

> My list has 8 different allowed
> shifts for I222, but I assume this is because the 0,0,1/2 shift is
> part of a symmetry operator.  I guess it is a matter of semantics as
> to wether or not that is an "allowed shift"?
>
> James, the (0,0,1/2) shift is not "part of" any symmetry operator in I222,
but I'm sure you knew that! - whereas the (1/2,1/2,1/2) shift _is_ a
symmetry operator: the I centring operator in fact.  This means that the
lattice repeating units of the crystal structures (i.e. the set of atomic
positions in the unit cell) will be identical in pairs, so in I222 (or
indeed any I-centred space group) the crystal structure obtaining by
shifting by (0,0,1/2) is identical in all respects to the one obtained from
the (1/2,1/2,0) shift.  In contrast, the structures obtained from all the
other pairs, e,g, (0,0,0) and (0,0,1/2), are different in all respects,
excepting that their sets of calculated amplitudes will be identical.

In your terminology a "non-allowed" origin shift is one which would cause
even the |Fc|s to differ, which is practice would mean that you would have
to use a different space-group specific formula for the structure factor (so
it's "non-allowed" only in the sense that you are "not allowed" to use the
same structure factor formula, but you "are allowed" to use a different
one).

I prefer to call it "non-equivalent origin shift" (as opposed to equivalent
origin or centring shift) - it's not really a question of whether it's
"allowed" or not, it's whether it has any effect on the crystal structure.
In practical terms of course it makes absolutely no difference to the result
if you choose to do things that have absolutely no effect!

Cheers

-- Ian

Re: [ccp4bb] Definition of B-factor (pedantry)

[Ian Tickle]

Hi Phil

My understanding is that when the B factor was devised it was believed
that it wouldn't represent any physical reality and was initially at
least widely regarded as a "garbage dump" for errors.  So it made no
difference whether or not it was related to the natural length in
reciprocal space, it was just a number, a "fudge factor" used to fit
the data.  Bs^2 is simplest to calculate from theta (which can be
measured directly from the film or diffractometer setting), lambda
(which is fixed of course) and B -  particularly if you don't have a
computer!  Also a significant point may be that the scattering factors
were tabulated as a function of s=sin(theta)/lambda (but you could
equally well ask why 2sin(theta)/lambda wasn't used there).  So it's
more convenient to have B multiplying s^2 since you can simply add B
to the constant part of the Gaussian scattering factor function.  Of
course they could have absorbed the extra factor of 2 into lambda
(i.e. use lambda/2 instead of lambda) but maybe no-one thought of
that!

U, the mean square displacement, is the quantity which is directly
related to the physics so if it's realism you're after, use U, not B
(or beta).

Cheers

-- Ian

On Wed, Oct 12, 2011 at 2:55 PM, Phil Evans  wrote:
> I've been struggling a bit to understand the definition of B-factors, 
> particularly anisotropic Bs, and I think I've finally more-or-less got my 
> head around the various definitions of B, U, beta etc, but one thing puzzles 
> me.
>
> It seems to me that the natural measure of length in reciprocal space is d* = 
> 1/d = 2 sin theta/lambda
>
> but the "conventional" term for B-factor in the structure factor expression 
> is exp(-B s^2) where s = sin theta/lambda = d*/2 ie exp(-B (d*/2)^2)
>
> Why not exp (-B' d*^2) which would seem more sensible? (B' = B/4) Why the 
> factor of 4?
>
> Or should we just get used to U instead?
>
> My guess is that it is a historical accident (or relic), ie that is the 
> definition because that's the way it is
>
> Does anyone understand where this comes from?
>
> Phil

Re: [ccp4bb] Definition of B-factor (pedantry)

[Ian Tickle]

Yet Uaniso's are multiplied by 1 and stored as integers with no problem!

-- Ian

On Thu, Oct 13, 2011 at 1:44 AM, James Holton  wrote:
> I think the PDB decided to store "B" instead of "U" because unless the
> B factor was > 80, there would always be a leading "0." in that
> column, and that would just be a pitiful waste of two bytes.  At the
> time the PDB was created, I understand bytes cost about $100 each!
> (But that could be a slight exaggeration)
>
> -James Holton
> MAD Scientist
>
> On Wed, Oct 12, 2011 at 2:56 PM, Phil Evans  wrote:
>> Indeed that paper does lay out clearly the various definitions, thank you, 
>> but I note that you do explicitly discourage use of B (= 8 pi^2 U), and 
>> don't explain why the factor is 8 rather than 2 (ie why it multiplies 
>> (d*/2)^2 rather than d*^2). I think James Holton's reminder that the 
>> definition dates from 1914 answers my question.
>>
>> So why do we store B in the PDB files rather than U?  :-)
>>
>> Phil
>>
>> On 12 Oct 2011, at 21:19, Pavel Afonine wrote:
>>
>>> This may answer some of your questions or at least give pointers:
>>>
>>> Grosse-Kunstleve RW, Adams PD:
>>> On the handling of atomic anisotropic displacement parameters.
>>> Journal of Applied Crystallography 2002, 35, 477-480.
>>>
>>> http://cci.lbl.gov/~rwgk/my_papers/iucr/ks0128_reprint.pdf
>>>
>>> Pavel
>>>
>>> On Wed, Oct 12, 2011 at 6:55 AM, Phil Evans  wrote:
>>> I've been struggling a bit to understand the definition of B-factors, 
>>> particularly anisotropic Bs, and I think I've finally more-or-less got my 
>>> head around the various definitions of B, U, beta etc, but one thing 
>>> puzzles me.
>>>
>>> It seems to me that the natural measure of length in reciprocal space is d* 
>>> = 1/d = 2 sin theta/lambda
>>>
>>> but the "conventional" term for B-factor in the structure factor expression 
>>> is exp(-B s^2) where s = sin theta/lambda = d*/2 ie exp(-B (d*/2)^2)
>>>
>>> Why not exp (-B' d*^2) which would seem more sensible? (B' = B/4) Why the 
>>> factor of 4?
>>>
>>> Or should we just get used to U instead?
>>>
>>> My guess is that it is a historical accident (or relic), ie that is the 
>>> definition because that's the way it is
>>>
>>> Does anyone understand where this comes from?
>>>
>>> Phil
>>>
>>
>

Re: [ccp4bb] REMARK REMARK 3 OVERALL ANISOTROPIC B VALUE.

[Ian Tickle]

Hi Stephen

You just multiply the Uij values in the ANISOU record by 8pi^2/1.

This begs the question why you want the Bij values in the first place
(since the Bij's don't correspond to any physical parameter)?  Note
that TLS parameters are on the same scale as U, not B.

Cheers

-- Ian

2011/10/13 Dr. STEPHEN SIN-YIN, CHUI :
> Dear all,
>
> can anyone tell me how to obtain the B11, B22, B33 values?
> After i performed the "anisotropic" refinement of the dataset at 1.6 A using
> REFMAC5, i can't read these values from the output PDB. thanks
>
> stephen
>
> --
> Dr. Stephen Sin-Yin Chui (徐先賢)
> Assistant Professor,
> Department of Chemistry,
> The University of Hong Kong, Pokfulam Road,
> Hong Kong SAR, China.
> Tel: 22415814 (Office), 22415818 (X-ray Diffraction Laboratory)
>

Re: [ccp4bb] Optimisation of weights

[Ian Tickle]

Hi Kavya

The resolutions of the structures mentioned in the paper were only
examples, the Rfree/-LLfree minimisation method (which are actually
due to Axel Brunger & Gerard Bricogne respectively) does not depend on
resolution.

If the structures are already solved & refined, you don't need to do
any model building, it should be within the radius of convergence with
the new weights - it's only a small adjustment after all.

Cheers

-- Ian

On Fri, Oct 14, 2011 at 6:12 AM,   wrote:
> Dear users,
>
> Can the optimization of the X-ray weighing factor
> and B-factor (overall wt) as mentioned in the paper
> Acta Cryst. (2007). D63, 1274–1281 by Dr.Ian Tickel,
> be used for the refinement of the data sets beyond
> the resolution range mentioned in the paper: 1.33 -
> 2.55 Ang?
>
> Also the structures that were used to optimize these
> parameters were already solved and refined, so when
> we are solving a new structure to what extent does the
> model has to be built before starting the optimization?
>
> Thanking you
> With Regards
> M. Kavyashree
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

[ccp4bb]

[Ian Tickle]

It must be the same complete model that you refined previously, I
doubt that it will give the correct answer if you leave out the waters
for example.

You say "there was quite a difference".  Could you be more specific:
what were the values of the weights, R factors and RMSZ(bonds/angles)
before and after weight optimisation?

Cheers

-- Ian

On Fri, Oct 14, 2011 at 8:42 AM,   wrote:
> Respected Sir,
>
> Thank you for your clarification. I had adopted this
> method recently. My doubt was if we have to optimize
> these two parameters during refinement, should we have
> the whole model along with water and ligands or only
> protein with few water positioning is enough. The reason
> why I am asking because there was quite a difference
> when I refined the same structure without the optimization
> and with optimization of these two parameters.
>
> Thanking you
> With regards
> M. Kavyashree
>
> -CCP4 bulletin board  wrote: -----
>
>    To: CCP4BB@JISCMAIL.AC.UK
>    From: Ian Tickle
>    Sent by: CCP4 bulletin board
>    Date: 10/14/2011 12:34PM
>    Subject: Re: [ccp4bb] Optimisation of weights
>
>    Hi Kavya
>
>    The resolutions of the structures mentioned in the paper were only
>    examples, the Rfree/-LLfree minimisation method (which are actually
>    due to Axel Brunger & Gerard Bricogne respectively) does not depend on
>    resolution.
>
>    If the structures are already solved & refined, you don't need to do
>    any model building, it should be within the radius of convergence with
>    the new weights - it's only a small adjustment after all.
>
>    Cheers
>
>    -- Ian
>
>    On Fri, Oct 14, 2011 at 6:12 AM,   wrote:
>    > Dear users,
>    >
>    > Can the optimization of the X-ray weighing factor
>    > and B-factor (overall wt) as mentioned in the paper
>    > Acta Cryst. (2007). D63, 1274–1281 by Dr.Ian Tickel,
>    > be used for the refinement of the data sets beyond
>    > the resolution range mentioned in the paper: 1.33 -
>    > 2.55 Ang?
>    >
>    > Also the structures that were used to optimize these
>    > parameters were already solved and refined, so when
>    > we are solving a new structure to what extent does the
>    > model has to be built before starting the optimization?
>    >
>    > Thanking you
>    > With Regards
>    > M. Kavyashree
>    >
>    >
>    > --
>    > This message has been scanned for viruses and
>    > dangerous content by MailScanner, and is
>    > believed to be clean.
>    >
>
>    --
>    This message has been scanned for viruses and
>    dangerous content by MailScanner, and is
>    believed to be clean.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

[ccp4bb]

[Ian Tickle]

Sorry I just re-read your last email and realised and didn't read it
properly the first time.  But what I said still stands: you can of
course try to optimise the weights at an early stage (before adding
waters say), there's no harm doing that, but there's also not much
point since you'll have to do it all again with the complete model,
since adding a lot of waters will undoubtedly change the optimal
weights.  So I just leave the weight optimisation until the model is
complete.  As long as the initial weights are "in the same ball park",
so that your RMSZ(bonds) is around 0.5 for typical resolutions (a bit
lower for low resolution, a bit higher for very high resolution) it
won't affect interpretation of maps etc.

Cheers

-- Ian

On Fri, Oct 14, 2011 at 9:37 AM, Ian Tickle  wrote:
> It must be the same complete model that you refined previously, I
> doubt that it will give the correct answer if you leave out the waters
> for example.
>
> You say "there was quite a difference".  Could you be more specific:
> what were the values of the weights, R factors and RMSZ(bonds/angles)
> before and after weight optimisation?
>
> Cheers
>
> -- Ian
>
> On Fri, Oct 14, 2011 at 8:42 AM,   wrote:
>> Respected Sir,
>>
>> Thank you for your clarification. I had adopted this
>> method recently. My doubt was if we have to optimize
>> these two parameters during refinement, should we have
>> the whole model along with water and ligands or only
>> protein with few water positioning is enough. The reason
>> why I am asking because there was quite a difference
>> when I refined the same structure without the optimization
>> and with optimization of these two parameters.
>>
>> Thanking you
>> With regards
>> M. Kavyashree
>>
>> -CCP4 bulletin board  wrote: -
>>
>>    To: CCP4BB@JISCMAIL.AC.UK
>>    From: Ian Tickle
>>    Sent by: CCP4 bulletin board
>>    Date: 10/14/2011 12:34PM
>>    Subject: Re: [ccp4bb] Optimisation of weights
>>
>>    Hi Kavya
>>
>>    The resolutions of the structures mentioned in the paper were only
>>    examples, the Rfree/-LLfree minimisation method (which are actually
>>    due to Axel Brunger & Gerard Bricogne respectively) does not depend on
>>    resolution.
>>
>>    If the structures are already solved & refined, you don't need to do
>>    any model building, it should be within the radius of convergence with
>>    the new weights - it's only a small adjustment after all.
>>
>>    Cheers
>>
>>    -- Ian
>>
>>    On Fri, Oct 14, 2011 at 6:12 AM,   wrote:
>>    > Dear users,
>>    >
>>    > Can the optimization of the X-ray weighing factor
>>    > and B-factor (overall wt) as mentioned in the paper
>>    > Acta Cryst. (2007). D63, 1274–1281 by Dr.Ian Tickel,
>>    > be used for the refinement of the data sets beyond
>>    > the resolution range mentioned in the paper: 1.33 -
>>    > 2.55 Ang?
>>    >
>>    > Also the structures that were used to optimize these
>>    > parameters were already solved and refined, so when
>>    > we are solving a new structure to what extent does the
>>    > model has to be built before starting the optimization?
>>    >
>>    > Thanking you
>>    > With Regards
>>    > M. Kavyashree
>>    >
>>    >
>>    > --
>>    > This message has been scanned for viruses and
>>    > dangerous content by MailScanner, and is
>>    > believed to be clean.
>>    >
>>
>>    --
>>    This message has been scanned for viruses and
>>    dangerous content by MailScanner, and is
>>    believed to be clean.
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>

[ccp4bb] "Insufficient virtual memory"

[Ian Tickle]

Hello all, some Fortran developer out there must know the answer to
this one.  I'm getting a "forrtl: severe (41): insufficient virtual
memory" error when allocating dynamic memory from a F95 program
compiled with Intel Fortran v11.1.059.  The program was compiled on an
old ia-32 Linux box with 1Gb RAM + 2Gb swap (I only have one Intel
license to compile on this machine), but I'm running it on a brand new
x86-64 box with 12Gb RAM + 8Gb swap.  This should be ample: the
program's maximum total memory requirement (code + static data +
dynamic data) should be no more than 3Gb.

My question is: what do I have to do to make it work?  According to
the ifort man page I need to specify "-mcmodel=medium -shared-intel".

It says: "If your program has COMMON blocks and local data with a
total size smaller than 2GB -mcmodel=small is sufficient.  COMMONs
larger than 2GB require mcmodel=medium or -mcmodel=large.  Allocation
of memory larger than 2GB can be done with any setting of -mcmodel."

I'm a bit confused about the difference here between COMMONS > 2Gb
(which I don't have) and "allocation of memory" > 2Gb (which I assume
I do).

When I try setting -mcmodel=medium (and -shared-intel) I get "ifort:
command line warning #10148: option '-mcmodel' not supported".  Is
this telling me that I have to compile on the 64-bit machine?
Whatever happened to cross-compilation?

All suggestions greatly appreciated!

-- Ian

Re: [ccp4bb] Optimisation of weights

[Ian Tickle]

Hi your X-ray weight of .08 seems very small, the optimal value is
normally in the range 1 to 4 (I usually set it initially at the
median, i.e. 2.5).  But which weight keyword did you use "WEIGHT
MATRIX .08" or "WEIGHT AUTO .08" (the latter is I think undocumented,
so I'm guessing the first)?  Anyway I would strongly advise the
latter: the difference is that the MATRIX weight is on a completely
arbitrary scale, whereas the AUTO weight is at least relative to the
theoretical value of 1 (even though the optimal value may not be 1 in
practice, at least your initial guess will be in the same ball park).
Note that what Refmac calls "automatic weighting" is not the same as
what X-PLOR, CNS & phenix call "automatic weighting" (at least that's
my understanding).  "WEIGHT AUTO" in Refmac is the same as "WEIGHT
AUTO 10", whereas auto-weighting in X-PLOR corresponds to "WEIGHT AUTO
1" in Refmac.  Not surprisingly these give quite different results!

The optimal B factor weight is also around 1, see the paper for typical values.

I'm still not clear precisely what you meant by ""there was quite a
difference".  I don't see that big a difference between the 2 runs,
just a slight tightening up of the geometry.  Are you saying you see
big differences in the refined co-ordinates?  That would be a cause
for concern.

Cheers

-- Ian

On Fri, Oct 14, 2011 at 11:19 AM,   wrote:
> Respected Sir,
>
> For one of the structures that I did optimisation
> had values - (resolution of the data - 2.35Ang)
>
> Before optimization- (Bfactor weight=1.0, X-ray Weight - auto)
> R factor  0.2362
> R free    0.2924
> -LLfree   7521.8
> rmsBOND   0.0160
> zBOND     0.660
>
> After optimisation- (B-factor weight=0.2, X-ray Weight - 0.08)
> R factor  0.2327
> R free    0.2882
> -LLfree   7495.7
> rmsBOND   0.0111
> zBOND     0.460
>
> Also can you tell me what is the limit for B-factor weight hat can be varied.
>
> Thanking you
> With Regards
> M. Kavyashree
>
>
> Sorry I just re-read your last email and realised and didn't read it
> properly the first time.  But what I said still stands: you can of
> course try to optimise the weights at an early stage (before adding
> waters say), there's no harm doing that, but there's also not much
> point since you'll have to do it all again with the complete model,
> since adding a lot of waters will undoubtedly change the optimal
> weights.  So I just leave the weight optimisation until the model is
> complete.  As long as the initial weights are "in the same ball park",
> so that your RMSZ(bonds) is around 0.5 for typical resolutions (a bit
> lower for low resolution, a bit higher for very high resolution) it
> won't affect interpretation of maps etc.
>
> Cheers
>
> -- Ian
>
> On Fri, Oct 14, 2011 at 9:37 AM, Ian Tickle  wrote:
>> It must be the same complete model that you refined previously, I
>> doubt that it will give the correct answer if you leave out the waters
>> for example.
>>
>> You say "there was quite a difference".  Could you be more specific:
>> what were the values of the weights, R factors and RMSZ(bonds/angles)
>> before and after weight optimisation?
>>
>> Cheers
>>
>> -- Ian
>>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

Re: [ccp4bb] "Insufficient virtual memory"

[Ian Tickle]

> Try the GNU (compiler) and see what it says. ;)

Hi Francois - I won't bore you with the long list of compiler errors
that gfortran gives with my code (ifort compiles the identical code
without error and up until now it has worked just fine on both 32 & 64
bit machines as long as don't try to allocate > 2Gb).

I think we'll have to splash out on an Intel license for a 64-bit
machine (thanks for the low-down on the bugs, Harry).

Anyway thanks to all for the suggestions.

Cheers

-- Ian

[ccp4bb]

[Ian Tickle]

> Yes, the weight mentioned in the paper was
> weight matrix, but the one i used was the
> option under "Refinement parameters- weighing
> term (when auto weighing is turned off)".
> But If I really wasnt to change the weight matrix
> where should I change (in the code?)?

No, the weights referred to in the paper are definitely the ones given
as "WEIGHT AUTO x".  I can say that with confidence because I never
use "WEIGHT MATRIX x" for reasons I explained.  I think what I said is
that it's _related_ to the matrix weight, which it obviously is by
some constant but unknown factor.

You don't have to change any code (that has been done for you!), but
if you're using CCP4I (sorry I don't so I can't give you precise
instructions), you probably have to edit the script before submission
(there should be a button in the "Run" menu for that).

Cheers

-- Ian

> No, I dint mean a big difference, not in the
> coordinates, but the values of R-factors and
> other terms. I thought it was quite different.
> So you mean that it is not of much concern?

I would say that it's not a big difference, just tightening up of the
geometry, as I said.

Cheers

-- Ian

[ccp4bb] PDB header info wrong.

[Ian Tickle]

Hi, currently Refmac writes the wrong info for the low resolution
cutoff, for example:

REMARK   3   PROGRAM : REFMAC 5.6.0119
REMARK   3  DATA USED IN REFINEMENT.
REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.00
REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  84.35

In contrast Shel-X puts in:

REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) : 10.00

The mtzdump of the MTZ file shows:

   1 NONE   -83   0  0  100.00-27.0 27.0  84.35   1.00   H  H
   2 NONE 0  97  0  100.00 54.9 54.9  84.35   1.00   H  K
   3 ASC  0  83  0  100.00 31.0 31.0  84.35   1.00   H  L
   4 NONE0.0 1.0 0  100.00 0.95 0.95  84.35   1.00   I  FREE
   5 NONE0.0  2071.8   435   99.82   125.22   125.22  10.00   1.00   F  FP
   6 NONE0.990.0   435   99.82 2.73 2.73  10.00   1.00
  Q  SIGFP

So obviously what has happened is that the Free R flags have been
generated to the high resolution cutoff and the low-res reflections,
i.e. below 10 Ang only have HKL & FREE defined.  Somewhere along the
line (this is data from the PDB) the low-res F's were lost.  So IMO
one cannot claim that these data were "used" in refinement.  Getting
tthe low-res cutoff wrong has a big effect on the electron density
that one expects for a given resolution range!  It seems to me that it
would be preferable to omit information rather than risk putting in
the wrong value, at least then one would know to go find the info
somewhere else.

Cheers

-- Ian

Re: [ccp4bb] atomic scattering factors in REFMAC

[Ian Tickle]

Hi, personally I didn't find that changing scattering factors for Se,
Br, I etc  made a big difference to the maps.  The more likely
explanation seems to be site occupancy disorder due to
radiation-induced breaking of covalent bonds, in which case you need
to refine the occupancy.  But maybe it's a bit of both.  I don't see
any harm in specifying the correct value of f' (as long as obviously
it is the correct value!).

Cheers

-- Ian

On Mon, Oct 31, 2011 at 3:57 PM, Ivan Shabalin  wrote:
> Dear Refmac users,
>
> I noticed that if I refine a structure containing SeMet, then Se atoms 
> usually have big negative (red) peeks of difference map and high B-factors. 
> As I understand from the diffraction theory and from some discussions at 
> CCP4bb, that may result because in REFMAC the atomic scattering factors are 
> internally coded for copper radiation (CuKa).
> I tried to use keyword "anomalous wavelength 0.9683" and found that with this 
> keyword I had different values of coefficient c for Se, Mn, and P as shown in 
> REFMAC log-file:
>
> loop_
>     _atom_type_symbol
>     _atom_type_scat_Cromer_Mann_a1
>     _atom_type_scat_Cromer_Mann_b1
>     _atom_type_scat_Cromer_Mann_a2
>     _atom_type_scat_Cromer_Mann_b2
>     _atom_type_scat_Cromer_Mann_a3
>     _atom_type_scat_Cromer_Mann_b3
>     _atom_type_scat_Cromer_Mann_a4
>     _atom_type_scat_Cromer_Mann_b4
>     _atom_type_scat_Cromer_Mann_c
>
>  N     12.2126   0.0057   3.1322   9.8933   2.0125  28.9975   1.1663   0.5826 
> -11.5290
>  C      2.3100  20.8439   1.0200  10.2075   1.5886   0.5687   0.8650  51.6512 
>   0.2156
>  H      0.4930  10.5109   0.3229  26.1257   0.1402   3.1424   0.0408  57.7997 
>   0.0030
>  O      3.0485  13.2771   2.2868   5.7011   1.5463   0.3239   0.8670  32.9089 
>   0.2508
>  SE    17.0006   2.4098   5.8196   0.2726   3.9731  15.2372   4.3543  43.8163 
>  -1.0329
>  MN    11.2819   5.3409   7.3573   0.3432   3.0193  17.8674   2.2441  83.7543 
>   1.3834
>  P      6.4345   1.9067   4.1791  27.1570   1.7800   0.5260   1.4908  68.1645 
>   1.2650
>
> As a result, red peeks around Se are significantly lower, Se B-factors are a 
> bit smaller (like 25.6 and 23.1), and Rf is lowered by a bit more than 0.1% 
> with the same input files.
>
> That looks pretty good. Still, I want to ask your opinion on the following:
>
> 1) Is it proper way to specify atomic scattering factors? I found this 
> keyword under REFMAC documentation topic "Simultaneous SAD experimental 
> phasing and refinement" and Im not sure if I change something else when I 
> specify the keyword. I dont have separate F+, F- and corresponding SIGF+, 
> SIGF- in my mtz, so SAD experimental phasing should not go.
> 2) Do you think it is safe to specify this keyword for every structure under 
> refinement? Can it have some drawbacks (except wrong wavelength)?
> As I understand, the theoretical Cromer_Mann curve can be different from 
> experimental, but still it is better than not to change scattering factor at 
> all.
>
> Thank you very much!!
>
> With best regards,
> Ivan Shabalin, Ph.D.
> Research Associate, University of Virginia
> 4-224 Jordan Hall, 1340 Jefferson Park Ave.
> Charlottesville, VA 22908
>

Re: [ccp4bb] atomic scattering factors in REFMAC

[Ian Tickle]

James, this doesn't take the effect of resolution cut-offs into
account, right?  You appear to be assuming that you have data to
atomic resolution (~ 1 A) or better.  The integral of the scattering
factor should be confined to the experimental resolution range,
otherwise it's not going to be very realistic, in fact the calculated
profile is not going to show the observed resolution dependence (and
where the density can go negative).  See slides 13 & 14 here
http://www.cse.scitech.ac.uk/events/CCP4_2011/talks/tickle.pdf for the
resolution-dependent version.

Cheers

-- Ian

On Wed, Nov 2, 2011 at 2:36 AM, James Holton  wrote:
> On Tue, Nov 1, 2011 at 3:32 PM, Ivan Shabalin  wrote:
>> Does that mean, that with Bf>10 we cannot distinguish Mg and water by 
>> electron density peak profile? Even if oxygen in water has twice as much 
>> bigger radius than Mg2+?
>
> Yup.  Pretty much.
>
> An "Mg+2" with B=10 is almost exactly the same density profile as a
> single point electron (atom type "Ano") with occ=9.72 and B=12.7.  You
> can also fit "water" (an "O" with two "H" atoms on top of it) to Mg+2,
> and get a pretty good fit with occ=1 and B=15 for the "water".  If you
> want to play around with this, I have placed a gnuplot-ish version of
> ${CLIBD}/atomsf.lib at:
>
> http://bl831.als.lbl.gov/~jamesh/pickup/all_atomff.gnuplot
>
> in gnuplot you can type:
> load 'all_atomff.gnuplot'
> plot Mg_plus_2_ff(x,20), O_ff(x,15)+2*H_ff(x,15)
>
> and stuff like that.
>
> -James Holton
> MAD Scientist
>

Re: [ccp4bb] how to skip map calculation in refmac

[Ian Tickle]

I can think of at least one good reason: you might want to optimise
the weights using different starting values.  In that case there's no
need to look at the maps until the end.  But as Eleanor says you can
always delete them.  I would do the weight optimisation with a
customised script, so this wouldn't be a problem anyway.

Cheers

-- Ian

On Thu, Nov 17, 2011 at 1:30 PM, Bosch, Juergen  wrote:
> I was wondering yesterday why one would do this and I'm sure the original
> poster has a particular reason for it - I just don't understand it.
> Are you burning CPU cycles for benchmarking proposes and don't want to bias
> the result based on slow hard discs or SSD's ?
> Jürgen
> On Nov 17, 2011, at 6:10 AM, Eleanor Dodson wrote:
>
> If you dont like it - delete it..
> Eleanor
>
>
> On 11/17/2011 09:29 AM, Tim Gruene wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
>
> Hash: SHA1
>
> Hi Ed,
>
> you can probably set hklout to /dev/null in order to not produce the
>
> output mtz-file, but this would not prevent refmac5 from doing the
>
> calculations.
>
> Tim
>
> On 11/17/2011 06:44 AM, Ed Pozharski wrote:
>
> Is there some way to make refmac *not* to produce the output mtz file,
>
> i.e. skip the whole FWT/DELFWT calculation altogether?
>
>
> - --
>
> - --
>
> Dr Tim Gruene
>
> Institut fuer anorganische Chemie
>
> Tammannstr. 4
>
> D-37077 Goettingen
>
> GPG Key ID = A46BEE1A
>
> -BEGIN PGP SIGNATURE-
>
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFOxNP5UxlJ7aRr7hoRArEDAJ47GIjsHrHoTWaeX8TBbbgPN2hLvACfSjcI
>
> fDNb5XUde3Jx/ZjQs5q1aLA=
>
> =dqb6
>
> -END PGP SIGNATURE-
>
> ..
> Jürgen Bosch
> Johns Hopkins University
> Bloomberg School of Public Health
> Department of Biochemistry & Molecular Biology
> Johns Hopkins Malaria Research Institute
> 615 North Wolfe Street, W8708
> Baltimore, MD 21205
> Office: +1-410-614-4742
> Lab:      +1-410-614-4894
> Fax:      +1-410-955-2926
> http://web.mac.com/bosch_lab/
>
>
>
>
>

Re: [ccp4bb] LESS MR pleae.. 1.95A, different phase

[Ian Tickle]

On Mon, Nov 21, 2011 at 10:23 AM, Eleanor Dodson  wrote:
> Just a plea for less molecular replacement.
>
> If you get a new crystal of a known protein with the  same cell dimension as
> youur old crystal, the most likely scenario is that it has the same group,
> and you really should not try MR - use the previous solution as input to do
> rigid body refinement, and then
>  a) the R factor will tell you if this is a reasonable hypothesis (it
> usually is..) and
> b) you dont have this awful problem of not being able to compare the
> solutions..
>
>  Eleanor

But sometimes (or actually we find quite often) the crystal after
soaking & freezing is sufficiently non-isomorphous (we sometimes see
up tp 10% changes in cell parameters) that RBR just doesn't work, and
then you have to fall back on MR.  The solution in that case to avoid
problems of generating symmetry-related and/or origin-shifted
molecules is to do a limited MR search, e.g. rotating/translating each
molecule in the a.u. independently by up to 5 deg & 5 Ang. from the
model (which of course has 100% similarity making it a lot easier).
Furthermore, because the number of points sampled is much less one can
afford to do the more accurate full 6-D search, as opposed to the
usual 3-D RF followed by 3-D TF on each RF solution.  So now we do
this routinely (we don't even bother with a preliminary RBR).  I
believe the limited 6-D search can be done with Phaser.

Cheers

-- Ian

Re: [ccp4bb] adxv

[Ian Tickle]

Rajesh

I use adxv (as well as xemacs, xdsview, imosflm, hklview, ipdisp etc)
over ssh/Cygwin X11 from Windows XP to a Centos (like RedHat) server
with no problems at all.

I suspect your  xming either just doesn't have the requisite X11 libs
or somehow they have not gotten installed on your system.  Can you try
Cygwin/X11, it's very easy to install.

Cheers

-- Ian

On 22 November 2011 13:49, Rajesh kumar  wrote:
> Dear Tim,
> Yes, I have windows 7 computer and use ccp4 and phenix through xming/putty
> and I run them over linux lab computer.
> Sorry if I have confused you all with insufficient information.
> On the lab linux system,  I installed everything you suggested in BASH and
> it works but not completely.
> Core manager kind of not interested to look in to it and I dont know much to
> understand everything you nice people saying here.
> So instead I used idiffdisp and it opens the image. But wanted adxv to work
> thats all.
> Thanks
> Raj
>> Date: Tue, 22 Nov 2011 14:41:00 +0100
>> From: t...@shelx.uni-ac.gwdg.de
>> To: ccp4...@hotmail.com
>> CC: CCP4BB@JISCMAIL.AC.UK
>> Subject: Re: [ccp4bb] adxv
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Dear Rajesh,
>>
>> are you saying that the computer you are sitting in front of is a
>> windows computer?
>> Are you sure you have been using CCP4 and phenix through an
>> ssh-connection and not the respective windows-binaries?
>>
>> I am not familiar with windows and the possible existence of
>> X11-clients, but I would think that most suggestions to you assumed that
>> your client computer was also a linux-machine.
>>
>> Cheers,
>> Tim
>>
>> On 11/22/2011 02:27 PM, Rajesh kumar wrote:
>> >
>> > I don't know if I need that installed on my windows computer terminal.On
>> > the server also I could run adxv. Thought of using other ccp4 utilities.
>> > Thanks for everyone for the help. I give up.
>> > Regards,Rajesh
>> >
>> >> Date: Mon, 21 Nov 2011 11:36:14 -0500
>> >> From: ber...@upstate.edu
>> >> Subject: Re: [ccp4bb] adxv
>> >> To: CCP4BB@JISCMAIL.AC.UK
>> >>
>> >> yum install lesstif ?
>> >>
>> >> but wouldn't the motif stuff be required for the X-server, i.e. your
>> >> terminal, not for the
>> >> server running adxv?
>> >>
>> >> Rajesh kumar wrote:
>> >>> Dear Mark,
>> >>>
>> >>> $ locate XKeysymDB - didnt come with any thing suggests probably
>> >>> openmotif lib is not
>> >>> installed.
>> >>> I linux server has Fedora and I am using latest version of Adxv so
>> >>> details on the sbgrid
>> >>> suggest its same problem.
>> >>>
>> >>> So how would I fix this.
>> >>>
>> >>> Thanks for your time.
>> >>>
>> >>> Regards
>> >>> Rajesh
>> >>>
>> >>>
>> >>> > Date: Sun, 20 Nov 2011 23:18:32 +
>> >>> > Subject: Re: [ccp4bb] adxv
>> >>> > From: mark.x.bro...@gmail.com
>> >>> > To: ccp4...@hotmail.com
>> >>> > CC: CCP4BB@jiscmail.ac.uk
>> >>> >
>> >>> > Dear Rajesh,
>> >>> > Are you using the Openmotif library? If so, do you
>> >>> > have an XKeysymDB file installed?
>> >>> > In as shell, issue:
>> >>> > $ locate XKeysymDB
>> >>> > You may need to symlink it to /usr/X11R6/lib/X11/XKeysymDB if it is
>> >>> > elsewhere [1].
>> >>> > I suspect you're not the only one to have seen this [2].
>> >>> >
>> >>> > I hope this helps.
>> >>> >
>> >>> > Mark
>> >>> > [1]
>> >>>
>> >>> ftp://ftp.parallelgeo.com/SPW_Products/Linux/Current_Release/ReadMe_for_recent_Linux_distributions.txt
>> >>> > [2] http://sbgrid.org/news/newsletters/2009/06 (search for the
>> >>> > string "adxv")
>> >>> >
>> >>> >
>> >>> > On 20 November 2011 19:45, Rajesh kumar  wrote:
>> >>> > >
>> >>> > > Dear Tim,
>> >>> > > Thanks. Your suggestion of adding to PATH works and its not
>> >>> > > completely functional may
>> >>> be due to the Ximg/ssh or some thing to do with display.
>> >>> > > All three windows opened but couldn't open any image as it didn't
>> >>> > > display in the list
>> >>> of autoload window. Pattern shows *.0.
>> >>> > >
>> >>> > > $adxv pin8_1_180.img
>> >>> > >
>> >>> > > (standard_in) 1: parse error
>> >>> > > (standard_in) 1: parse error
>> >>> > > (standard_in) 1: parse error
>> >>> > > beam_center x = pixels , mm
>> >>> > > beam_center y = pixels , mm
>> >>> > > distance = mm
>> >>> > > overload = counts
>> >>> > > pixelsize = 0.172 mm
>> >>> > > wavelength = Angstroem
>> >>> > > Adxv Version 1.9.4-beta
>> >>> > > Copyright (C) 1994-2007 by Andrew Arvai, Area Detector Systems
>> >>> > > Corporation
>> >>> > > Using 24-bit TrueColor visual
>> >>> > > Warning: translation table syntax error: Unknown keysym name:
>> >>> > > osfActivate
>> >>> > > Warning: ... found while parsing ':osfActivate:
>> >>> > > ManagerParentActivate()'
>> >>> > > Warning: String to TranslationTable conversion encountered errors
>> >>> > > Warning: translation table syntax error: Unknown keysym name:
>> >>> > > osfBeginLine
>> >>> > > Warning: ... found while parsing ':osfBeginLine:
>> >>> > > ManagerGadgetTraverseHome()'
>> >>> > > Warning: String to TranslationTable conversion encoun

Re: [ccp4bb] adxv-SOLVED

[Ian Tickle]

sfActivate:
>> > PrimitiveParentActivate()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfActivate
>> > Warning: ... found while parsing ':osfActivate:
>> > PrimitiveParentActivate()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfSelect
>> > Warning: ... found while parsing ':osfSelect:
>> > ArmAndActivate()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfPrimaryPaste
>> > Warning: ... found while parsing ':m
>> > osfPrimaryPaste:cut-primary()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfSelect
>> > Warning: ... found while parsing ':osfSelect:
>> > ManagerGadgetSelect()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfSelect
>> > Warning: ... found while parsing ':osfSelect:
>> > MenuBarGadgetSelect()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfActivate
>> > Warning: ... found while parsing ':osfActivate:
>> > ManagerParentActivate()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name: osfHelp
>> > Warning: ... found while parsing ':osfHelp:
>> > MenuHelp()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfActivate
>> > Warning: ... found while parsing ':osfActivate:
>> > PrimitiveParentActivate()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfActivate
>> > Warning: ... found while parsing ':osfActivate:
>> > DrawingAreaInput() ManagerParentActivate()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name: osfUp
>> > Warning: ... found while parsing ':osfUp:
>> > DrawingAreaInput() ManagerGadgetTraverseUp()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfSelect
>> > Warning: ... found while parsing ':osfSelect: KeySelect()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfSelect
>> > Warning: ... found while parsing ':osfSelect: KeySelect()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfCancel
>> > Warning: ... found while parsing 'osfCancel:
>> > MenuEscape()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfBeginLine
>> > Warning: ... found while parsing ':s c osfBeginLine:
>> > ListBeginDataExtend()'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: translation table syntax error: Unknown keysym name:
>> > osfBeginLine
>> > Warning: ... found while parsing ':c osfBeginLine:
>> > ActionGrab(SWTopLine)'
>> > Warning: String to TranslationTable conversion encountered errors
>> > Warning: Locale not supported for XmbTextListToTextProperty
>> > Warning: Cannot convert XmString to compound text
>> > Warning: Locale not supported for XmbTextListToTextProperty
>> > Warning: Cannot convert XmString to compound text
>> > No such file: 0.172
>> >
>> >
>> > Loading predictions from: -wavelength
>> > error: can not open: -wavelength
>> >
>> >
>> >
>> >
>> > Thanks
>> > Rajesh
>> >
>> > > Date: Tue, 22

Re: [ccp4bb] adxv-SOLVED

[Ian Tickle]

On 22 November 2011 22:04, Pius Padayatti  wrote:
> Rajesh,
> The fonts error please follow the guidelines from following link
>
> http://www.scripps.edu/~arvai/adxv.html

OK the fonts you need are the ones mentioned above (in
http://www.scripps.edu/~arvai/adxv/fonts.tar.gz), BUT the installation
instructions there are for an X server running on Linux.  It won't do
you any good to install them on the Linux system disk, unless it
happens to be mounted on your Windows PC (possible though unlikely).
The logical place to install them is with the Xming X server on your
Windows PC (or you could put them on any disk that's mounted from your
Windows PC).  For that you need to follow these instructions:

http://www.straightrunning.com/XmingNotes/fonts.php

Cheers

Re: [ccp4bb] negative density in difference map [SEC=UNCLASSIFIED]

[Ian Tickle]

Hi Careina

Since my name came up I felt compelled to comment, though I don't have
a definitive answer.  Over-restraining of B factors is certainly a
possibility and could well explain otherwise inexplicable difference
density.  IMO B factors are generally over-restrained.  They are a bit
like the R factors: tight restraints keep the B factors low and people
(referees in particular!) seem to feel happier when they see low
values, even though that is not necessarily optimal (this mind-set is
of course known as "wishful thinking" - see Wikipedia article).

Personally I never restrain 1-3 B factors, and only use the 1-2
restraints, and even then I relax those from the default values.  The
1-3 B restraints are clearly not independent of the 1-2 ones, and
restraints should ideally be independent of each other, otherwise you
are applying them more than once,  IMO the overall B factor restraint
weight should be optimised in the same way that the X-ray weight
should be, by minimising Rfree or -LLfree.  X-plor, CNS (and I would
guess phenix.refine) have had this option for many years
(optimize_rweight.inp in CNS), and it seems an excellent thing to do,

Disorder is also an obvious possibility as Anthony said, and I would
follow his sensible advice.

Cheers

-- Ian

Cheers

-- Ian

On 23 November 2011 10:58, Eleanor Dodson  wrote:
> I wish I could answer this!
> One possibility is that the side-chain B values are too tightly restrained -
> Ian Tickle recommends releasing these somewhat..
>
> Here are the default refmac values.
> THERMAL FACTORS
>          Weight= 1.00
>     Main chain bond (1-2 neighbour)          1.5A**2
>     Main chain angle (1-3 neighbour)         2.0A**2
>     Side chain bond                          3.0A**2
>     Side chain angle                         4.5A**2
>
> and you could change them say to:
>
>
> Under GUI - check geometric parameters and alter the Bfactor values
>
> data line becomes:  temp 1.0     1.5 2.0  4.0 6.0
>
> The trouble is that resyraints for ARG or MET say should be looser than
> those for SER or VAL.
>
> But I often finish up with some inexplicable red blobs - sometimes floating
> in space..
> Eleanor
>
>
> On 11/23/2011 08:39 AM, DUFF, Anthony wrote:
>>
>>
>> Delete (set occupancies to zero) the side chain back to CA.  Do a few
>> rounds of refinement and calculate Fo-Fc and examine.
>>
>>
>>
>
>
>> It is possible that the side chain is disordered, or ordered in multiple
>> conformations.  Compare the density for alternate confonformers against the
>> density for CA.
>>
>>
>>
>> Alternatively, your side chain B-factor restaints might be too tight.
>>
>>
>>
>> Anthony
>>
>>
>>
>>
>>
>> 
>> From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Careina
>> Edgooms [careinaedgo...@yahoo.com]
>> Sent: Wednesday, 23 November 2011 6:54 PM
>> To: CCP4BB@JISCMAIL.AC.UK
>> Subject: [ccp4bb] negative density in difference map
>>
>> Good morning CCP4 members
>>
>> I have a question about a 2F0-Fc difference map that I calculated with
>> Refmac. In some instances it gives me negative (red) density around part of
>> a side chain and no positive density in sight. Furthermore the entire
>> residue fits well into the blue density of the complete map, including the
>> part with negative density.
>> I am struggling to interpret this. Does the fact that it fits the blue
>> density mean that the side chain is in the correct place or does the red
>> blob on part of the side chain (eg on the sulphur in a Met residue) mean
>> that something funky is happening with this side chain?
>>
>> Thanks for any assistance
>> Careina
>>
>

Re: [ccp4bb] negative density in difference map

[Ian Tickle]

On 23 November 2011 07:54, Careina Edgooms  wrote:
> I have a question about a 2F0-Fc difference map that I calculated with Refmac.

On 23 November 2011 15:40, Nat Echols  wrote:
> The negative density around Met S could be radiation damage.

But you wouldn't expect to see -ve density in the 2Fo-Fc map from
radiation damage right?  The Fo-Fc map for sure.

Cheers

-- Ian

Re: [ccp4bb] negative density in difference map

[Ian Tickle]

I assumed that since this topic came up fairly recently, in fact 3
weeks ago (see thread starting from
http://www.mail-archive.com/ccp4bb@jiscmail.ac.uk/msg23628.html), it
wasn't just a re-run of the same question.

Perhaps the original poster could clarify whether we are talking about
unexplained -ve density in the 2Fo-Fc map or in the Fo-Fc map?

Cheers

-- Ian

On 23 November 2011 16:03, Nat Echols  wrote:
> On Wed, Nov 23, 2011 at 7:57 AM, Ian Tickle  wrote:
>> On 23 November 2011 07:54, Careina Edgooms  wrote:
>>> I have a question about a 2F0-Fc difference map that I calculated with 
>>> Refmac.
>>
>> On 23 November 2011 15:40, Nat Echols  wrote:
>>> The negative density around Met S could be radiation damage.
>>
>> But you wouldn't expect to see -ve density in the 2Fo-Fc map from
>> radiation damage right?  The Fo-Fc map for sure.
>
> I assumed that's what the original poster meant.
>
> (and I apologize for the redundant comments, GMail groups messages by
> subject, so every time someone changes the subject line, it becomes a
> new thread, which I usually miss.  That said, I thought after reading
> Garib's Refmac paper published earlier this year that it was now using
> distance-based B-factor restraints, instead of bond connectivity - is
> this correct or did I misunderstand?)
>
> -Nat
>

Re: [ccp4bb] Script problem

[Ian Tickle]

Simon

This appears to be a csh or tcsh script: if so the first line must be
"#!/bin/csh" or "#!/bin/tcsh", otherwise it takes it to be a sh
script.

Cheers

-- Ian

On 2 December 2011 14:45, Simon Kolstoe  wrote:
> Hi there,
>
> I've got a text file with multiple conformations of a ligand that has been 
> docked to a protein using autodock, which I am trying to split into separate 
> pdb files in order to visualise in pymol/coot etc.
>
> Previously I've used the script pasted below, but it is now falling over just 
> after it creates the pdb file with the error:
>
> expr: syntax error
> csplit: }: bad repetition count
> ./split_results.com: line 11: syntax error near unexpected token `('
> ./split_results.com: line 11: `foreach f ($outputname.[0-9][0-9][0-9])'
>
> Can any of you wizzy programmers give me a hand with getting this to work 
> again? (it's on a mac just in the normal terminal)
>
> Thanks,
>
> Simon
>
> The script:
>
> #!
> grep '^DOCKED' output.dlg | cut -c9- > my_docking.pdbqt
> cut -c-66 my_docking.pdbqt > my_docking.pdb
> # csh to split pdb files from autodock output.
> # edit outputname.
> #
> set outputname=output
> set a=`grep ENDMDL my_docking.pdb | wc -l`
> set b=`expr $a - 2`
> csplit -k -s -n 3 -f $outputname. my_docking.pdb '/^ENDMDL/+1' '{'$b'}'
> foreach f ($outputname.[0-9][0-9][0-9])
> mv $f $f.pdb
> end

Re: [ccp4bb] PHENIX vs REFMAC refinement had me fooled

[Ian Tickle]

On 13 December 2011 17:59, James Holton  wrote:
> A small but potentially important correction:
>
> FC_ALL PHIC_ALL from REFMAC are indeed the calculated structure factor of
> the coordinates+bulk_solvent, but AFTER multiplying by the likelihood
> coefficient "D" (as in 2*m*Fo-D*Fc ).  So, if you subtract ( FC_ALL PHIC_ALL
> ) from ( FC PHIC ) you will NOT get the bulk solvent contribution alone.
>  AFAIK there is no way to obtain just the bulk solvent contribution from
> REFMAC.

James, I agree completely!  But I would venture to go further and say
that the FC/PHIC values really have no business being in the output
MTZ file in the first place, so if they weren't there then the
question of subtracting them would never arise.  They are the result
of intermediate calculations, the kind of things I print out when I'm
debugging a program to aid in checking the logic.  The FC_ALL/PHIC_ALL
values represent the final definitive result of the refinement, so in
all applications where Fcalc is required (e.g. density correlation
stats) DFc/phi(DFc) should always be used - and why would one want to
omit part of the model anyway (unless maybe for an omit map - but that
doesn't seem to be relevant here)?

Fc/phic is the transform of the refined atomic model parameters as
output in XYZOUT which essentially is just a snapshot of the model.
DFc/phi(DFc) represents the transform of an ensemble average of a
distribution of models generated by the random co-ordinate (and other
parameter) errors, and of course everyone knows that X-ray diffraction
measures the ensemble average, not a shapshot.

Also we know that (2mFo-DFc)/phic (or mFo/phic if centric) is the best
estimate of the true phased F.  The best estimate of the difference
Ftrue-Fmodel is the difference coefficient 2(mFo-DFc)/phic (or
mFo-DFc)/phic if centric).  So the best estimate of Fmodel is clearly
(Ftrue - (Ftrue - Fmodel))/phic = (2mFo - DFc - 2(mFo - DFc))/phic =
DFc/phic (and the same result for centric).

Cheers

-- Ian

Re: [ccp4bb] refmac low resolution REMARK

[Ian Tickle]

Hi Bernhard

So what's new?  See
http://ccp4bb.blogspot.com/2011/11/pdb-header-info-wrong.html
(17-Nov-11).

Cheers

-- Ian


On 2 January 2012 06:58, Bernhard Rupp (Hofkristallrat a.D.)
 wrote:
> Dear Developers,
>
> it seems to me that at least Refmac 5.6.0117 does not report the actual
> lowest resolution used in refinement, but instead the lowest resolution of
> the hkl index range generated by the default cif import script instead.
>
> REMARK   3  DATA USED IN REFINEMENT.
> REMARK   3   RESOLUTION RANGE HIGH (ANGSTROMS) :   1.99
> REMARK   3   RESOLUTION RANGE LOW  (ANGSTROMS) :  38.63 <---
>
>  The data go only to 28.66 A according to mtzdump as well as xprep
>
>  as far as I can tell, cif2mtz does it right and reports
>
> * Cell Dimensions : (obsolete - refer to dataset cell dimensions above)
>
>   33.1300   57.2300   38.6500   90.   91.9400   90.
>
>  *  Resolution Range :
>
>    0.00122    0.25305     (     28.660 -      1.988 A ) < -
>
> then the script calls unique  which pads the reflections up
>
>  * Cell Dimensions : (obsolete - refer to dataset cell dimensions above)
>
>   33.1300   57.2300   38.6500   90.   91.9400   90.
>
>  *  Resolution Range :
>
>    0.00067    0.25302     (     38.628 -      1.988 A ) <-
>
> which then propagates to CAD and FREEFLAG into the MTZ header where it is
> picked up by refmac.
>
> OVERALL FILE STATISTICS for resolution range   0.001 -   0.253
>  ===
>  Col Sort    Min    Max    Num      %     Mean     Mean   Resolution   Type
> Column
>  num order               Missing complete          abs.   Low    High
> label
>
>   1 ASC    -16      16      0  100.00      0.1      6.3  38.63   1.99   H
> H
>   2 NONE     0      28      0  100.00     10.5     10.5  38.63   1.99   H
> K
>   3 NONE     0      19      0  100.00      7.3      7.3  38.63   1.99   H
> L
>   4 NONE    0.0     9.0     0  100.00     4.50     4.50 38.63 1.99   I
> FREE
>   5 NONE    7.7   707.8   361   96.40   102.76   102.76  28.66   1.99   F
> FP <- this is the right number!
>   6 NONE    1.6    37.3   361   96.40     8.84     8.84  28.66   1.99   Q
> SIGFP
>
>
> I have noticed that other PDB/sf file sets (not mine) seem to be affected as
> well.
>
> Best regards, BR
> -
> Bernhard Rupp
> 001 (925) 209-7429
> +43 (676) 571-0536
> b...@ruppweb.org
> hofkristall...@gmail.com
> http://www.ruppweb.org/
> -
> No animals were hurt or killed during the
> production of this email.
> -

Re: [ccp4bb] unusual bond lengths in PRODRG cif file

[Ian Tickle]

On 9 January 2012 06:13, Shveta Bisht  wrote:
> Dear all
>
> I have generated a refmac cif file for a molecule using PRODRG. I used
> JME editor to draw the molecule and ran PRODRG online with the
> options: Chirality-Yes, Charges-Reduced and EM-Yes. Please check the
> attachments for the molecule drawing and the expected bond lengths as
> listed in the PRODRG generated cif file. There are some unusual
> values. I have listed them below along with the likely explanations
> (just guesses).
>
> DRG      CAR    CAK       single      1.390    0.025
> DRG      CAQ    CAB       single      1.390    0.025
> DRG      CAT    CAI       single      1.390    0.020
> All three are C-C single bonds where one of the carbons belong to
> aromatic ring. This might lead to a short bond, although 1.39 seems to
> be too short for this.
>
> DRG      CAI    NAL       double      1.340    0.022
> DRG      CAP    NAL       single      1.340    0.022
> Here N and both the carbons are sp2 hybridization, so there can be
> delocalization of electrons. Thus both bonds (single and double) are
> of similar length.
>
> DRG      CAP    CAA       double      1.530    0.025
> As mentioned above, if pi (unhybridized) electrons of CAP are involved
> in CAP NAL bonding, then CAP CAA double bond essentially becomes a
> single bond with 1.53 bond length.
>
> I need advise on the way I have run prodrg and the explanations for the 
> results.
> Is it common to observe such values? Or it is due to the alternating single 
> and
> double bonds in this structure.

Dear Shveta

I agree completely with your assessment, there are certainly some
"unusual" values, but I think this goes beyond "mistakes".  I have run
your structure through our own dictionary auto-generation software
which essentially takes suitable fragments from the CSD and stitches
them together (similar to CCDC-MOGUL but it doesn't use MOGUL and the
pieces are smaller).

Here are the values I get for comparison:

> DRG  CARCAK   single  1.3900.025 1.512(10)
> DRG  CAQCAB   single  1.3900.025 1.498(7)
> DRG  CATCAIsingle  1.3900.020  1.449(24)
> DRG  CAI NAL   double 1.3400.022  1.273(13)
> DRG  CAPNAL   single  1.3400.022  1.350(28)
> DRG  CAPCAA   double1.5300.025  1.329(21)

so essentially backing up what you said.

My suspicion is that it's not generally recognised the central role
played by bond length & angle restraints in MX refinement (after all
if they weren't important then we wouldn't need to use them!), and as
a consequence some people seem to think that their exact values are
unimportant and "anything will do".  Their importance soon becomes
obvious (particularly of course at medium-low resolution) if you try
to do unrestrained refinement: then you can easily get deviations 10
times greater than you get with restraints.  So personally I believe
in using the most accurate restraints possible and "anything will NOT
do".

My main concern would be that grossly inaccurate values such as these
find their way into the PDB and then people base their restraints on
these structures (though it's not a great idea to use the PDB
co-ordinates as a source of restraints!).

Before you ask, unfortunately our software is not available for
distribution but I can recommend GRADE from Global Phasing which gives
very high quality restraints; there's also of course JLigand from
CCP4, though I haven't used it personally and so cannot attest for the
quality.

Cheers

-- Ian

Re: [ccp4bb] Always Modelling Anomalous Signal

[Ian Tickle]

Jacob,

Actually the R factors including the Bijvoet pairs would be higher,
because the uncertainties in F(+) and F(-) are higher than that of
F(mean) by a factor of about sqrt(2).  R factors will always be higher
for unmerged data because averaging always reduces the uncertainty.
This means that we are in effect 'cheating' by throwing away the
relatively imprecise anomalous differences and getting falsely lower R
factors as a result!  But as you imply the model would improve if we
included the anomalous data in the refinement (assuming of course that
it is meaningful data).  This just demonstrates that low R factors do
not necessarily equate to a better model - especially if you
deliberately throw away the less precise data!  The model would
improve (marginally) because the anomalous differences would obviously
provide additional information about the anomalous scatterers and
therefore increase their precision, but wouldn't affect the precision
of the lighter atoms.  But is imprecision in the parameters of the
heavy (or heavier) atoms usually an issue? - since these have bigger
real scattering factors they will be more precisely determined than
the lighter atoms anyway.  So I don't think you would gain very much,
except maybe more truthful R factors!

Cheers

-- Ian

On 10 January 2012 20:00, Jacob Keller  wrote:
> Dear Crystallographers,
>
> it seems to me that on a certain level we are always throwing away
> (sort of) about half of our data when we merge Bijvoet pairs--why
> shouldn't we keep them separate, since we know that they should be a
> little bit different, especially in light of the higher multiplicities
> which are more common now? Shouldn't modelling them give better
> R-values, and wouldn't it just be more true? I guess a sort of proof
> for this is that sulfurs are almost always detectable on anomalous
> difference maps, implying that we are actually measuring those
> differences accurately enough to see them (I don't think these things
> can arise from model bias, as anomalous differences are not modeled.)
> At least maybe at the final steps of refinement...?
>
> JPK
>
> --
> ***
> Jacob Pearson Keller
> Northwestern University
> Medical Scientist Training Program
> email: j-kell...@northwestern.edu
> ***

Re: [ccp4bb] NMR review

[Ian Tickle]

On 12 January 2012 09:57, Dirk Kostrewa  wrote:

> That doesn't sound wrong to me: the flexible parts are at different relative
> positions in the unit cells and thus their "partial-structure scattering
> waves" do not have a constant phase relation to each other, i.e., they don't
> give a coherent contribution to the total scattering.

>From http://scienceworld.wolfram.com/physics/IncoherentScattering.html
: "Scattering for which reemission occurs by a cascade process, so the
frequency of emission is not the same as that of the incident. ".

We don't see any change of frequency (or wavelength) in the majority
of the scattering from disordered regions so it's Rayleigh (coherent)
scattering.  There will be a small amount of Compton (incoherent)
scattering resulting from the ionisation events which are responsible
for radiation damage but hopefully freezing will keep this to a
minimum.

Cheers

-- Ian

Re: [ccp4bb] NMR review

[Ian Tickle]

> We don't see any change of frequency (or wavelength) in the majority
> of the scattering from disordered regions so it's Rayleigh (coherent)
> scattering.  There will be a small amount of Compton (incoherent)
> scattering resulting from the ionisation events which are responsible
> for radiation damage but hopefully freezing will keep this to a
> minimum.

Sorry just re-read that & realised the bit about freezing is not quite
what I meant!  Freezing will not of course reduce the amount of
incoherent scattering in the least.  It may however alleviate its
effects (which is what I meant).

Cheers

-- Ian

Re: [ccp4bb] NMR review

[Ian Tickle]

On 12 January 2012 10:33, Dirk Kostrewa  wrote:
> My understanding of coherence is a constant phase relation between waves.

Correct.  For a perfect crystal all the unit cells are identical so
they scatter in phase
and this gives rise to the interference effect we see as Bragg spots,
as you say arising
from a constant phase relation in specific directions.  For a disordered
crystal the unit cells are not the same: this destroys the
interference effect but there's
still a constant phase relation in any specified direction so it's
still coherent.

> Of course, this breaks down for inelastic scattering, but (in)coherence can
> also be described without any change in wavelength.

That's not the definition of incoherence used by the physicists.  Of
course you're
free to redefine it but I think that just confuses everyone.

Cheers

-- IAn

Re: [ccp4bb] NMR review

[Ian Tickle]

On 12 January 2012 11:25, Dirk Kostrewa  wrote:
> I'm not a physicist - but isn't (in)coherence also used to describe the
> property of sources of electromagnetic waves with constant wavelength? For
> instance, an incoherent sodium vapour light source (only looking at one
> emission band) compared to a coherent Laser, or the incoherent emission from
> a conventional X-ray source or an X-ray undulator compared to a
> Free-electron-X-ray-Laser? If yes, then we could describe diffraction from a
> crystal in a similar way by treating the crystal as a "light-source", both
> with coherent and incoherent scattering from the well-ordered and disordered
> parts, respectively, without any need to change the wavelength. In this
> analogy, the ordered part would have the coherence of a Laser, whereas the
> disordered part would have the incoherence of a vapour lamp.

I'm not a physicist either but if I look up 'coherence' in Wikipedia
(not necessarily the most accurate source of information I admit!):

"The most monochromatic sources are usually lasers; such high
monochromaticity implies long coherence lengths (up to hundreds of
meters). For example, a stabilized helium-neon laser can produce light
with coherence lengths in excess of 5 m. Not all lasers are
monochromatic, however (e.g. for a mode-locked Ti-sapphire laser, Δλ ≈
2 nm - 70 nm). LEDs are characterized by Δλ ≈ 50 nm, and tungsten
filament lights exhibit Δλ ≈ 600 nm, so these sources have shorter
coherence times than the most monochromatic lasers." (
http://en.wikipedia.org/wiki/Coherence_%28physics%29 ).

So coherence is indeed directly related to monochromaticity so there's
no energy dispersion on elastic scattering.  Of course X-rays from any
source will also have (more or less depending on the physics of X-ray
production) a characteristic Δλ which implies some degree of
incoherence in the incident and therefore the scattered beams.  The
question though is whether or not the scattering event adds to this
intrinsic incoherence.  When we talk about 'coherent scattering' we
mean that the degree of incoherence of the scattered beam is unchanged
relative to that of the incident beam.

Cheers

-- Ian


Cheers

-- Ian

Re: [ccp4bb] NMR review

[Ian Tickle]

On 12 January 2012 13:02, Weiergräber, Oliver H.
 wrote:
> I think the problem is related to the term "coherence" being used to describe 
> both the type of *radiation* and the mode of *scattering*.
> When talking about (xray) radiation, it denotes the phase relationship 
> between photons, and therefore even a monochromatic beam can be incoherent 
> (whereas a polychromatic one is, of course, always incoherent). In terms of 
> scattering, however, what matters is the self-coherence between different 
> "partial waves" scatted from different unit cells. Taking things this way, 
> the classical crystallographic diffraction experiment with a rotating anode 
> actually makes use of coherent scattering of an incoherent beam!

I think you're right, one can consider 2 types of coherence: temporal
or longitudinal coherence which is measured by the average
auto-correlation function of the wave with a copy of itself displaced
by some time interval, and spatial or lateral coherence which is
measured by the average cross-correlation function of one part of the
wave-front with another part at the same instant in time.  Spatial
coherence is obviously relevant to diffraction because different parts
of the wave-front get scattered by different parts of the crystal, so
if there's disorder it will lead to spatial decoherence (aka diffuse
scattering).  In scattering we are considering what happens when an
X-ray photon interacts with an electron so then temporal decoherence
will only occur if in an inelastic collision the photon loses some of
its energy to the electron.  So one must take care to distinguish
"(in)coherent scattering" from "(in)coherent diffraction".

Cheers

-- Ian

Re: [ccp4bb] MAD

[Ian Tickle]

Perhaps I could chime in with a bit of history as I understand it.

The term 'dispersion' in optics, as everyone who knows their history
is aware of, refers to the classic experiment by Sir Isaac Newton at
Trinity College here in Cambridge where he observed white light being
split up ('dispersed') into its component colours by a prism.  This is
of course due to the variation in refractive index of glass with
wavelength, so then we arrive at the usual definition of optical
dispersion as dn/dlambda, i.e. the first derivative of the refractive
index with respect to the wavelength.

Now the refractive index of an average crystal at around 1 Ang
wavelength differs by about 1 part in a million from 1, however it can
be determined by very careful and precise interferometric experiments.
 It's safe to say therefore that the dispersion of X-rays (anomalous
or otherwise) has no measurable effect whatsoever as far as the
average X-ray diffraction experiment (SAD, MAD or otherwise) is
concerned.  The question then is how did the term 'anomalous
dispersion' get to be applied to X-ray diffraction?  The answer is
that it turns out that the equation ('Kramer-Kronig relationship')
governing X-ray scattering is completely analogous to that governing
optical dispersion, so it's legitimate to use the term 'dispersive'
(meaning 'analogous to dispersion') for the real part of the
wavelength-dependent component of the X-ray scattering factor, because
the real part of the refractive index is what describes dispersion
(the imaginary part in both cases describes absorption).

So then from 'dispersive' to 'dispersion' to describe the wavelength
dependence of X-ray scattering is only a short step, even though it
only behaves _like_ dispersion in its dependence on wavelength.
However having two different meanings for the same word can get
confusing and clearly should be avoided if at all possible.

So what does this have to do with the MAD acronym?  I think it stemmed
from a visit by Wayne Hendrickson to Birkbeck in London some time
around 1990: he was invited by Tom Blundell to give a lecture on his
MAD experiments.  At that time Wayne called it multi-wavelength
anomalous dispersion.  Tom pointed out that this was really a misnomer
for the reasons I've elucidated above.  Wayne liked the MAD acronym
and wanted to keep it so he needed a replacement term starting with D
and diffraction was the obvious choice, and if you look at the
literature from then on Wayne at least consistently called it
multi-wavelength anomalous diffraction.

Cheers

-- Ian

On 18 January 2012 18:23, Phil Jeffrey  wrote:
> Can I be dogmatic about this ?
>
> Multiwavelength anomalous diffraction from Hendrickson (1991) Science Vol.
> 254 no. 5028 pp. 51-58
>
> Multiwavelength anomalous diffraction (MAD) from the CCP4 proceedings
> http://www.ccp4.ac.uk/courses/proceedings/1997/j_smith/main.html
>
> Multi-wavelength anomalous-diffraction (MAD) from Terwilliger Acta Cryst.
> (1994). D50, 11-16
>
> etc.
>
>
> I don't see where the problem lies:
>
> a SAD experiment is a single wavelength experiment where you are using the
> anomalous/dispersive signals for phasing
>
> a MAD experiment is a multiple wavelength version of SAD.  Hopefully one
> picks an appropriate range of wavelengths for whatever complex case one has.
>
> One can have SAD and MAD datasets that exploit anomalous/dispersive signals
> from multiple difference sources.  This after all is one of the things that
> SHARP is particularly good at accommodating.
>
> If you're not using the anomalous/dispersive signals for phasing, you're
> collecting native data.  After all C,N,O,S etc all have a small anomalous
> signal at all wavelengths, and metalloproteins usually have even larger
> signals so the mere presence of a theoretical d" difference does not make it
> a SAD dataset.  ALL datasets contain some anomalous/dispersive signals, most
> of the time way down in the noise.
>
> Phil Jeffrey
> Princeton
>
>
>
> On 1/18/12 12:48 PM, Francis E Reyes wrote:
>>
>>
>> Using the terms 'MAD' and 'SAD' have always been confusing to me when
>> considering more complex phasing cases.  What happens if you have intrinsic
>> Zn's, collect a 3wvl experiment and then derivatize it with SeMet or a heavy
>> atom?  Or the MAD+native scenario (SHARP) ?
>>
>> Instead of using MAD/SAD nomenclature I favor explicitly stating whether
>> dispersive/anomalous/isomorphous differences (and what heavy atoms for each
>> ) were used in phasing.   Aren't analyzing the differences (independent of
>> source) the important bit anyway?
>>
>>
>> F
>>
>>
>> -
>> Francis E. Reyes M.Sc.
>> 215 UCB
>> University of Colorado at Boulder

Re: [ccp4bb] writing scripts-off topic

[Ian Tickle]

On 24 January 2012 14:19, David Schuller  wrote:
> On 01/24/12 00:41, Bart Hazes wrote:
> www.cs.siue.edu/~astefik/papers/StefikPlateau2011.pdf
>
> An Empirical Comparison of the Accuracy Rates of Novices using the Quorum,
> Perl, and Randomo Programming Languages
> A. Stefik, S. Siebert, M. Stefik, K. Slattery
>
> Abstract: "... Perl users were unable to write programs more accurately than
> those using a language designed by chance."

... and from the same paper: "Students tell us that the syntax they
are learning (in C++ at our school), makes no sense and some have
difficulty writing even basic computer programs.".

Maybe the difficulty the students in the test group experienced had a
lot to do with the fact they were complete novices and had no
experience whatsoever of any computer language; also the language
syntax was not explained to them prior to the test, they had to deduce
it during the test time itself (21 mins) from code samples.

Note that Python wasn't tested, so the fact that they found Perl
syntax difficult to deduce from the samples doesn't necessarily imply
that they wouldn't also have had the same difficulty with Python.  One
of the difficulties reported with Perl was the use of the 'for'
keyword to introduce a loop (novices apparently report that 'repeat'
is 7 times more intuitive than 'for').  But Python and Perl (and C/C++
of course) both use the 'for' keyword in a loop construct, and maybe
all this paper proves is that 'repeat' is easier to comprehend than
'for' (or any other loop syntax)!  I remember when I first learned
Fortran the 'DO' loop was the hardest concept to grasp (not so much
the syntax, but the concept of looping itself, with variables
potentially having different values on each pass through the loop):
this was followed closely by the FORMAT statement!  I think every
programming novice finds the concept of looping difficult at first in
whatever language they are using: you can often recognise novice code
because it studiously avoids the use of loops!

Personally I think there's plenty of opportunity to write bad (and
good) code in any language; for me the choice of language is a
personal one and not one I lose any sleep over.  Far more important to
me than writing beautiful code is getting the algorithm right,
particularly as it affects numerical precision.  Debugging the syntax
is the easy bit, debugging the algorithm is always the hard part.

Cheers

-- Ian

Re: [ccp4bb] Problem with getting Rfree and Rf down

[Ian Tickle]

On 24 January 2012 15:23, Greg Costakes  wrote:
> It would seem that you have a large model bias. Rule of thumb is to keep
> R/Rfree within 5% of each other. If you find that the numbers
> are separating during refinement you need to reduce the weighting factor
> (dont use automatic) during refinement. What is your overall redundancy?

Reducing the AUTO weighting factor will have exactly the same effect
as reducing the MATRIX factor: if you examine the Refmac code you'll
see they both end up modifying the reflection weights.  I find the
default value of 10 for the AUTO factor much too high once the
structure has been completely built and refinement is progressing.  If
a structure is already refined (e.g. protein-ligand work) I tend to
start at WEIGHT AUTO 4 or even 2.5 and work down towards WA=1.  This
is the theoretically correct value (which is why I prefer to have the
weight in units of WA instead of the completely arbitrary 'MATRIX'
units), but usually it ends up being a little higher than 1 presumably
because of some residual model errors.

Cheers

-- Ian

Re: [ccp4bb] writing scripts-off topic

[Ian Tickle]

On 24 January 2012 08:59, Tim Gruene  wrote:

> [flame=;-)]
> P.S.: don't use python. It's a nightmare language, sloppy, it forces you
> to format the code in a specific way rather than your own way and ...
> [/flame]

I'm inclined to go along with you there: the main reason I've put off
learning Python is that it uses spacing characters (space, tab and
newline) as an integral part of the syntax and I've always felt
uncomfortable with that (memories of fixed format code and data I
suppose!).  Somehow a semicolon at the end of the line has a
reassuring air of finality!  Maybe a Python expert will answer this
but I've often wondered, what happens if as some editors do
(particularly if as I do you have to use different editors at
different times depending on where you are working, such as on Windows
working remotely from home or Linux at work), you could have a mixture
of space and tab characters in the file?  Often you don't know what
space/tab characters the editor is putting in and you shouldn't have
to know: the principle should be that if it looks right in the editor
then it is right.  So does Python automatically expand the tabs to the
equivalent number of spaces or (as in data input) are they treated as
single characters?  And anyway how does Python know what tab stops my
editors are set to and indeed how exactly my editors treat tabs?  The
appearance of the file doesn't tell you what's going on, e.g. N spaces
followed by a tab looks exactly the same as just a tab if N <8.  I
would hope that the answer is that I don't need to worry about any of
this!

Cheers

-- Ian

Re: [ccp4bb] MAD

[Ian Tickle]

Hi Peter

You are right: the location of the prism experiment is most likely the
study at Woolsthorpe, e.g. see
http://www.isaacnewton.org.uk/texts/OfColours7 .  Newton was admitted
to Trinity College in 1661 as a 'sizar' (a paid part-time student
employed by the College) but was forced to return to Woolsthorpe (the
family home) in August 1665 (http://www.isaacnewton.org.uk/Chronology)
to continue studying privately, because the University closed
temporarily as a precaution against the Great Plague ('Black Death')
which was spreading outwards from the initial outbreak in this country
in the London Docklands during the summer of that year.  He returned
to Trinity in 1667 as a Fellow of the College.

So I should have been more precise and said that Newton performed the
prism experiment during the time that he was associated with Trinity
(it's not clear what the nature of his association with Trinity was
during the 2 years he spent doing experiments at Woolsthorpe).

Cheers

-- Ian

On 28 January 2012 09:35, Peter Moody  wrote:
> Ian,
> If you visit Isaac Newton's old home at Woolsthorpe (near here) you will see
> a conflicting claim for location of the classic prism experiment. You will
> also find an apple tree in the garden, but that is another story..
>
> Peter
>
> PS this is my special ccp4bb email account, it doesn't always get the
> attention it deserves.
>
>
> On 19 January 2012 17:50, Ian Tickle  wrote:
>>
>> Perhaps I could chime in with a bit of history as I understand it.
>>
>> The term 'dispersion' in optics, as everyone who knows their history
>> is aware of, refers to the classic experiment by Sir Isaac Newton at
>> Trinity College here in Cambridge where he observed white light being
>> split up ('dispersed') into its component colours by a prism.  This is
>> of course due to the variation in refractive index of glass with
>> wavelength, so then we arrive at the usual definition of optical
>> dispersion as dn/dlambda, i.e. the first derivative of the refractive
>> index with respect to the wavelength.
>>
>> Now the refractive index of an average crystal at around 1 Ang
>> wavelength differs by about 1 part in a million from 1, however it can
>> be determined by very careful and precise interferometric experiments.
>>  It's safe to say therefore that the dispersion of X-rays (anomalous
>> or otherwise) has no measurable effect whatsoever as far as the
>> average X-ray diffraction experiment (SAD, MAD or otherwise) is
>> concerned.  The question then is how did the term 'anomalous
>> dispersion' get to be applied to X-ray diffraction?  The answer is
>> that it turns out that the equation ('Kramer-Kronig relationship')
>> governing X-ray scattering is completely analogous to that governing
>> optical dispersion, so it's legitimate to use the term 'dispersive'
>> (meaning 'analogous to dispersion') for the real part of the
>> wavelength-dependent component of the X-ray scattering factor, because
>> the real part of the refractive index is what describes dispersion
>> (the imaginary part in both cases describes absorption).
>>
>> So then from 'dispersive' to 'dispersion' to describe the wavelength
>> dependence of X-ray scattering is only a short step, even though it
>> only behaves _like_ dispersion in its dependence on wavelength.
>> However having two different meanings for the same word can get
>> confusing and clearly should be avoided if at all possible.
>>
>> So what does this have to do with the MAD acronym?  I think it stemmed
>> from a visit by Wayne Hendrickson to Birkbeck in London some time
>> around 1990: he was invited by Tom Blundell to give a lecture on his
>> MAD experiments.  At that time Wayne called it multi-wavelength
>> anomalous dispersion.  Tom pointed out that this was really a misnomer
>> for the reasons I've elucidated above.  Wayne liked the MAD acronym
>> and wanted to keep it so he needed a replacement term starting with D
>> and diffraction was the obvious choice, and if you look at the
>> literature from then on Wayne at least consistently called it
>> multi-wavelength anomalous diffraction.
>>
>> Cheers
>>
>> -- Ian
>>
>> On 18 January 2012 18:23, Phil Jeffrey  wrote:
>> > Can I be dogmatic about this ?
>> >
>> > Multiwavelength anomalous diffraction from Hendrickson (1991) Science
>> > Vol.
>> > 254 no. 5028 pp. 51-58
>> >
>> > Multiwavelength anomalous diffraction (MAD) from the CCP4 proceedings
>> > http://www.ccp4.ac.uk/courses

Re: [ccp4bb] Reasoning for Rmeas or Rpim as Cutoff

[Ian Tickle]

Jacob, here's my (personal) take on this:

The data quality metrics that everyone uses clearly fall into 2
classes: 'consistency' metrics, i.e. Rmerge/meas/pim and CC(1/2) which
measure how well redundant observations agree, and signal/noise ratio
metrics, i.e. mean(I/sigma) and completeness, which relate to the
information content of the data.

IMO the basic problem with all the consistency metrics is that they
are not measuring the quantity that is relevant to refinement and
electron density maps, namely the information content of the data, at
least not in a direct and meaningful way.  This is because there are 2
contributors to any consistency metric: the systematic errors (e.g.
differences in illuminated volume and absorption) and the random
errors (from counting statistics, detector noise etc.).  If the data
are collected with sufficient redundancy the systematic errors should
hopefully largely cancel, and therefore only the random errors will
determine the information content.  Therefore the systematic error
component of the consistency measure (which I suspect is the biggest
component, at least for the strong reflections) is not relevant to
measuring the information content.  If the consistency measure only
took into account the random error component (which it can't), then it
would be essentially be a measure of information content, if only
indirectly (but then why not simply use a direct measure such as the
signal/noise ratio?).

There are clearly at least 2 distinct problems with Rmerge, first it's
including systematic errors in its measure of consistency, second it's
not invariant with respect to the redundancy (and third it's useless
as a statistic anyway because you can't do any significance tests on
it!).  The redundancy problem is fixed to some extent with Rpim etc,
but that still leaves the other problems.  It's not clear to me that
CC(1/2) is any better in this respect, since (as far as I understand
how it's implemented), one cannot be sure that the systematic errors
will cancel for each half-dataset Imean, so it's still likely to
contain a large contribution from the irrelevant systematic error
component and so mislead in respect of the real data quality exactly
in the same way that Rmerge/meas/pim do.  One may as well use the
Rmerge between the half dataset Imeans, since there would be no
redundancy effect (i.e. the redundancy would be 2 for all included
reflections).

I did some significance tests on CC(1/2) and I got silly results, for
example it says that the significance level for the CC is ~ 0.1, but
this corresponded to a huge Rmerge (200%) and a tiny mean(I/sigma)
(0.4).  It seems that (without any basis in statistics whatsoever) the
rule-of-thumb CC > 0.5 is what is generally used, but I would be
worried that the statistics are so far divorced from the reality - it
suggests that something is seriously wrong with the assumptions!

Having said all that, the mean(I/sigma) metric, which on the face of
it is much more closely related to the information content and
therefore should be a more relevant metric than Rmerge/meas/pim &
CC(1/2), is not without its own problems (which probably explains the
continuing popularity of the other metrics!).  First and most obvious,
it's a hostage to the estimate of sigma(I) used.  I've never been
happy with inflating the counting sigmas to include effects of
systematic error based on the consistency of redundant measurements,
since as I indicated above if the data are collected redundantly in
such a way that the systematic errors largely cancel, it implies that
the systematic errors should not be included in the estimate of sigma.
 The fact that then the sigma(I)'s would generally be smaller (at
least for the large I's), so the sample variances would be much larger
than the counting variances, is irrelevant, because the former
includes the systematic errors.  Also the I/sigma cut-off used would
probably not need to be changed since it affects only the weakest
reflections which are largely unaffected by the systematic error
correction.

The second problem with mean(I/sigma) is also obvious: i.e. it's a
mean, and as such it's rather insensitive to the actual distribution
of I/sigma(I).  For example if a shell contained a few highly
significant intensities these could be overwhelmed by a large number
of weak data and give an insignificant mean(I/sigma).  It seems to me
that one should be considering the significance of individual
reflections, not the shell averages.  Also the average will depend on
the width of the resolution bin, so one will get the strange effect
that the apparent resolution will depend on how one bins at the data!
The assumption being made in taking the bin average is that I/sigma(I)
falls off smoothly with d* but that's unlikely to be the reality.

It seems to me that a chi-square statistic which takes into account
the actual distribution of I/sigma(I) would be a better bet than the
bin average, though it's not entirely clear how o

Re: [ccp4bb] odd behaviour of reindex

[Ian Tickle]

On 31 January 2012 02:30, Jens Kaiser  wrote:
> Hi all,
>  we encountered an odd behaviour of REINDEX.
>
> Snip form logfile:
>
>  Data line--- reindex HKL (h+l)/2, -k, (h-l)/2
>  Data line--- end
>
>  Reflections will be reindexed, and unit cell recalculated
>
>  Reindexing transformation:
>       (h' k' l') =  ( h  k  l ) (  1.0  0.0  1.0 )
>                                 (  0.0 -1.0  0.0 )
>                                 (  0.5  0.0 -0.5 )
>
> Obviously, the first line of the matrix is not what we intended to
> create.
>
> inputting the transformation as HKL h/2+l/2, -k, h/2-l/2
> produces the desired result:
>
>  Data line--- reindex HKL h/2+l/2, -k, h/2-l/2
>  Data line--- end
>
>  Reflections will be reindexed, and unit cell recalculated
>
>  Reindexing transformation:
>       (h' k' l') =  ( h  k  l ) (  0.5  0.0  0.5 )
>                                 (  0.0 -1.0  0.0 )
>                                 (  0.5  0.0 -0.5 )
>
>
>
> Admittedly, the documentation does not use any brackets in the examples,
> but i would expect REINDEX either to throw an error or treat (h+l)/2
> like (h-l)/2 but not treat them in the way encountered.

Jens

Reindex is not treating (h+l)/2 any differently from (h-l)/2, they are
being treated identically, i.e. it is simply ignoring the brackets in
both cases (which is why expanding the expressions without brackets
works)..

So (h+l)/2 is being treated as though you had specified h+l/2 and
(h-l)/2 becomes h-l/2.

Don't forget that the rule for matrix multiplication is row-by-column,
not row-by-row!

Cheers

-- Ian

Re: [ccp4bb] odd behaviour of reindex

[Ian Tickle]

Eleanor

Maybe the interpreter should at least throw an error if it encounters
a character (such as a bracket) that it can't interpret, as Jens
implied.

Cheers

-- Ian

On 31 January 2012 10:16, Eleanor Dodson  wrote:
> Sorry, but  it is a pain writing interpreters - at least it was in Fortran!
> and once you have one which recognises slashes as divisors, brackets can
> seem a step too far!
>
> Eleanor
>
>
> On 01/31/2012 08:46 AM, Phil Evans wrote:
>>
>> I had hoped that Pointless could replace Reindex, but doing some test it
>> seems that it also has problems with the syntax of reindex operators. I need
>> to look into this (but perhaps not immediately, sorry)
>>
>> Phil
>>
>>
>> On 31 Jan 2012, at 02:30, Jens Kaiser wrote:
>>
>>> Hi all,
>>>  we encountered an odd behaviour of REINDEX.
>>>
>>> Snip form logfile:
>>>
>>> Data line--- reindex HKL (h+l)/2, -k, (h-l)/2
>>> Data line--- end
>>>
>>>  Reflections will be reindexed, and unit cell recalculated
>>>
>>> Reindexing transformation:
>>>       (h' k' l') =  ( h  k  l ) (  1.0  0.0  1.0 )
>>>                                 (  0.0 -1.0  0.0 )
>>>                                 (  0.5  0.0 -0.5 )
>>>
>>> Obviously, the first line of the matrix is not what we intended to
>>> create.
>>>
>>> inputting the transformation as HKL h/2+l/2, -k, h/2-l/2
>>> produces the desired result:
>>>
>>> Data line--- reindex HKL h/2+l/2, -k, h/2-l/2
>>> Data line--- end
>>>
>>>  Reflections will be reindexed, and unit cell recalculated
>>>
>>> Reindexing transformation:
>>>       (h' k' l') =  ( h  k  l ) (  0.5  0.0  0.5 )
>>>                                 (  0.0 -1.0  0.0 )
>>>                                 (  0.5  0.0 -0.5 )
>>>
>>>
>>>
>>> Admittedly, the documentation does not use any brackets in the examples,
>>> but i would expect REINDEX either to throw an error or treat (h+l)/2
>>> like (h-l)/2 but not treat them in the way encountered.
>>>
>>> Cheers,
>>>
>>> Jens
>>>
>>>
>>> --
>>> +-+-+
>>> | Jens T. Kaiser                      | Office: +1(626)395-2662     |
>>> | California Institute of Technology  | Lab:    +1(626)395-8392     |
>>> | m/c 114-96                          | Cell:   +1(626)379-1650     |
>>> | 1200 E. California Blvd.            | Xray:   +1(626)395-2661     |
>>> | Pasadena, CA 91125                  | Email:  kai...@caltech.edu  |
>>> | USA                                 | Skype:  jens.t.kaiser       |
>>> +-+-+

Re: [ccp4bb] Fwd: HR3699, Research Works Act

[Ian Tickle]

Reading the H.R.3699 bill as put forward
(http://thomas.loc.gov/cgi-bin/bdquery/z?d112:HR03699:@@@L&summ2=m&;)
it seems to be about prohibiting US federal agencies from having
policies which permit, authorise or require authors' assent to break
the law of copyright in respect of published journal articles
describing work funded at least in part by a US federal agency.  I'm
assuming that "network dissemination without the publisher's consent"
is the same thing as breaking the law of copyright.

It seems to imply that it would still be legal for US federal agencies
to encourage others to break the law of copyright in respect of
journal articles describing work funded by say UK funding agences! -
or is there already a US law in place which prohibits that?  I'm only
surprised that encouraging others to break the law isn't already
illegal (even for Govt agencies): isn't that the law of incitement
(http://en.wikipedia.org/wiki/Incitement)?

This forum in fact already has such a policy in place for all journal
articles (i..e not just those funded by US federal agencies but by all
funding agencies), i.e. we actively discourage postings which incite
others to break the law by asking for copies of copyrighted published
articles.  Perhaps the next petition should seek to overturn this
policy?

This petition seems to be targeting the wrong law: if what you want is
free flow of information then it's the copyright law that you need to
petition to overturn, or you get around it by publishing in someplace
that doesn't require transfer of copyright.

Cheers

-- Ian

On 16 February 2012 09:35, Tim Gruene  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear Raji,
>
> maybe you could increase the number of supporters if you included a link
> to (a description of) the content of HR3699 - I will certainly not sign
> something only summarised by a few polemic sentences ;-)
>
> Cheers,
> Tim
>
> On 02/15/2012 11:53 PM, Raji Edayathumangalam wrote:
>> If you agree, please signing the petition below. You need to register on
>> the link below before you can sign this petition. Registration and signing
>> the petition took about a minute or two.
>>
>> Cheers,
>> Raji
>>
>> -- Forwarded message --
>> From: Seth Darst 
>> Date: Tue, Feb 14, 2012 at 12:40 PM
>> Subject: HR3699, Research Works Act
>> To:
>>
>>
>> Rep. Caroline Maloney has not backed off in her attempt to put forward the
>> interests of Elsevier and other academic publishers.
>>
>> If you oppose this measure, please sign this petition on the official 'we
>> the people' White House web site. It needs 23,000 signatures before
>> February 22nd and only 1100 so far. Please forward far and wide.
>>
>>
>> Oppose HR3699, the Research Works Act
>>
>> HR 3699, the Research Works Act will be detrimental to the free flow of
>> scientific information that was created using Federal funds. It is an
>> attempt to put federally funded scientific information behind pay-walls,
>> and confer the ownership of the information to a private entity. This is an
>> affront to open government and open access to information created using
>> public funds.
>>
>> This link gets you to the petition:
>> https://wwws.whitehouse.gov/petitions#!/petition/oppose-hr3699-research-works-act/vKMhCX9k
>>
>>
>>
>>
>>
>
> - --
> - --
> Dr Tim Gruene
> Institut fuer anorganische Chemie
> Tammannstr. 4
> D-37077 Goettingen
>
> GPG Key ID = A46BEE1A
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFPPM3kUxlJ7aRr7hoRAsKYAKDIs/jZHPBIV4AB2qrpBdXrSOn+VwCePabR
> Nm6+LK17jLJnPTqkjsQ4fV8=
> =a27t
> -END PGP SIGNATURE-

Re: [ccp4bb] Fwd: HR3699, Research Works Act

[Ian Tickle]

quite well under a
>> policy that
>> gives them a year of exclusive control over papers, followed by open
>> access.
>>
>>    It is, unfortunately, a standard ploy in current American politics to
>> make  a
>> law which does something likely to be very unpopular and very unreasonable
>> sound like it is a law doing something quite different.
>>
>>    Please reread it carefully.  I think you will join in opposing this
>> law.  Science
>> benefits from the NIH open access policy and the rights of all concerned
>> are respected.  It would be a mistake to allow the NIH open access policy
>> to
>> be killed.
>>
>>    I hope you will sign the petition.
>>
>>    Regards,
>>      Herbert
>>
>>
>> On 2/16/12 6:29 AM, Ian Tickle wrote:
>>
>>>
>>> Reading the H.R.3699 bill as put forward
>>> (http://thomas.loc.gov/cgi-bin/bdquery/z?d112:HR03699:@@@L&summ2=m&;)
>>> it seems to be about prohibiting US federal agencies from having
>>> policies which permit, authorise or require authors' assent to break
>>> the law of copyright in respect of published journal articles
>>> describing work funded at least in part by a US federal agency.  I'm
>>> assuming that "network dissemination without the publisher's consent"
>>> is the same thing as breaking the law of copyright.
>>>
>>> It seems to imply that it would still be legal for US federal agencies
>>> to encourage others to break the law of copyright in respect of
>>> journal articles describing work funded by say UK funding agences! -
>>> or is there already a US law in place which prohibits that?  I'm only
>>> surprised that encouraging others to break the law isn't already
>>> illegal (even for Govt agencies): isn't that the law of incitement
>>> (http://en.wikipedia.org/wiki/Incitement)?
>>>
>>> This forum in fact already has such a policy in place for all journal
>>> articles (i..e not just those funded by US federal agencies but by all
>>> funding agencies), i.e. we actively discourage postings which incite
>>> others to break the law by asking for copies of copyrighted published
>>> articles.  Perhaps the next petition should seek to overturn this
>>> policy?
>>>
>>> This petition seems to be targeting the wrong law: if what you want is
>>> free flow of information then it's the copyright law that you need to
>>> petition to overturn, or you get around it by publishing in someplace
>>> that doesn't require transfer of copyright.
>>>
>>> Cheers
>>>
>>> -- Ian
>>>
>>> On 16 February 2012 09:35, Tim Gruene   wrote:
>>>
>>>
>>>>
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA1
>>>>
>>>> Dear Raji,
>>>>
>>>> maybe you could increase the number of supporters if you included a link
>>>> to (a description of) the content of HR3699 - I will certainly not sign
>>>> something only summarised by a few polemic sentences ;-)
>>>>
>>>> Cheers,
>>>> Tim
>>>>
>>>> On 02/15/2012 11:53 PM, Raji Edayathumangalam wrote:
>>>>
>>>>
>>>>>
>>>>> If you agree, please signing the petition below. You need to register
>>>>> on
>>>>> the link below before you can sign this petition. Registration and
>>>>> signing
>>>>> the petition took about a minute or two.
>>>>>
>>>>> Cheers,
>>>>> Raji
>>>>>
>>>>> -- Forwarded message --
>>>>> From: Seth Darst
>>>>> Date: Tue, Feb 14, 2012 at 12:40 PM
>>>>> Subject: HR3699, Research Works Act
>>>>> To:
>>>>>
>>>>>
>>>>> Rep. Caroline Maloney has not backed off in her attempt to put forward
>>>>> the
>>>>> interests of Elsevier and other academic publishers.
>>>>>
>>>>> If you oppose this measure, please sign this petition on the official
>>>>> 'we
>>>>> the people' White House web site. It needs 23,000 signatures before
>>>>> February 22nd and only 1100 so far. Please forward far and wide.
>>>>>
>>>>>
>>>>> Oppose HR3699, the Research Works Act
>>>>>
>>>>> HR 3699, the Re

Re: [ccp4bb] Fwd: HR3699, Research Works Act

[Ian Tickle]

> Can non-US based scientists sign the petition, btw?

Well there's nothing to stop you!  It asks for your zip code, but I
just left it blank and it accepted it.

Cheers

-- Ian

Re: [ccp4bb] Fwd: HR3699, Research Works Act

[Ian Tickle]

Pedro,

Well it worked for me (and I see many others) without a zip code.  I
see that someone else typed "Bayreuth" in the zip code field - so I
suspect you can type anything there!

Cheers

-- Ian

On 16 February 2012 16:31, Pedro M. Matias  wrote:
>
> Can non-US residents sign this petition? You need a Whitehouse.gov account
> and in order to register you have to provide a U.S. (I presume) zipcode.
>
>
> At 15:37 16-02-2012, Ian Tickle wrote:
>>
>> Dear Herbert
>>
>> Thanks for your detailed explanation.  I had missed the important
>> point that it's the requirement on the authors to assent to open
>> access after a year, which the proposed Bill seeks to abolish, that's
>> critical here.
>>
>> I will go and sign the petition right now!
>>
>> Best wishes
>>
>> -- Ian
>>
>> On 16 February 2012 15:24, Herbert J. Bernstein
>>  wrote:
>> > The bill summary says:
>> >
>> > Research Works Act - Prohibits a federal agency from adopting,
>> > maintaining,
>> > continuing, or otherwise engaging in any policy, program, or other
>> > activity
>> > that: (1) causes, permits, or authorizes network dissemination of any
>> > private-sector research work without the prior consent of the publisher;
>> > or
>> > *(2) requires that any actual or prospective author, or the author's
>> > employer, assent to such network dissemination. *
>> >
>> > Defines "private-sector research work" as an article intended to be
>> > published in a scholarly or scientific publication, or any version of
>> > such
>> > an article, that is not a work of the U.S. government, describing or
>> > interpreting research funded in whole or in part by a federal agency and
>> > to
>> > which a commercial or nonprofit publisher has made or has entered into
>> > an
>> > arrangement to make a value-added contribution, including peer review or
>> > editing, but does not include progress reports or raw data outputs
>> > routinely
>> > required to be created for and submitted directly to a funding agency in
>> > the
>> > course of research.
>> >
>> > ==
>> >
>> > It is the second provision that really cuts the legs out from the NIH
>> > open
>> > access policy. What the NIH policy does is to make open access
>> > publication a
>> > condition imposed on the grant holders in publishing work that the NIH
>> > funded. This has provided the necessary lever for NIH-funded authors to
>> > be
>> > able to publish in well-respected journals and still to be able to
>> > require
>> > that, after a year, their work be available without charge to the
>> > scientific
>> > community. Without that lever we go back to the unlamented old system
>> > (at
>> > least unlamented by almost everybody other than Elsevier) in which
>> > pubishers
>> > could impose an absolute copyright transfer that barred the authors from
>> > ever posting copies of their work on the web. People affiliated with
>> > libraries with the appropriate subscriptions to the appropriate
>> > archiving
>> > services may not have noticed the difference, but for the significant
>> > portions of both researchers and students who did not have such access,
>> > the
>> > NIH open access policy was by itself a major game changer, making much
>> > more
>> > literature rapidly accessible, and even more importantly changed the
>> > culture, making open access much more respectable.
>> >
>> > The NIH policy does nothing more than put grant-sponsored research on
>> > almost
>> > the same footing as research done directly by the government which has
>> > never
>> > been subject to copyright at all, on the theory that, if the tax-payers
>> > already paid for the research, they should have open access to the
>> > fruits of
>> > that research. This law would kill that policy. This would be a major
>> > step
>> > backwards.
>> >
>> > Please read:
>> >
>> >
>> > http://blogs.scientificamerican.com/evo-eco-lab/2012/01/16/mistruths-insults-from-the-copyright-lobby-over-hr-3699/
>> >
>> > http://www.taxpayeraccess.org/action/action_access/12-0106.shtml
>> >
>> > http://www.care2.com/causes/open-access-under-threat-hr-3699.html
>> >
>> > Please support the pet

Re: [ccp4bb] proper or improper ncs?

[Ian Tickle]

Francis,

It's very easy to spot a 2-fold rotation or screw because the matrix
must be symmetric (or nearly so)**.  Your matrix very obviously is not
(i,e, A12 ne A21, A13 ne A31 etc).

** Proof:

 A rotation matrix is orthogonal, which implies inverse = transpose: A^-1 = A~.

A 2-fold rotation is proper which implies AA = I or A^-1 = A.

Take these together and you get A = A~ i.e. A is symmetric.

Surprising how many people aren't aware of this!

Cheers

-- Iann

On 21 February 2012 13:47, Francis E Reyes  wrote:
> Hi all
>
> This structure has the following ncs (output via phenix.simple_ncs_from_pdb)
> OPERATOR 1
> CENTER:   18.3443  -55.4605   23.0986
>
> ROTA 1:    1.    0.    0.
> ROTA 2:    0.    1.    0.
> ROTA 3:    0.    0.    1.
> TRANS:     0.    0.    0.
>
> OPERATOR 2
> CENTER:   37.0405  -23.8676  -14.9388
>
> ROTA 1:   -0.5444   -0.2202    0.8094
> ROTA 2:    0.8330   -0.0278    0.5526
> ROTA 3:   -0.0991    0.9751    0.1985
> TRANS:    45.3456  -78.7231   53.0085
>
>
> It looks two-foldish but I'm not sure if it's proper or improper. (I'm trying 
> to rationalize the lack of peaks on the self rotation maps).
>
>
> Any help would be appreciated.
>
> F
>
>
>
> -
> Francis E. Reyes M.Sc.
> 215 UCB
> University of Colorado at Boulder

Re: [ccp4bb] sudden drop in R/Rfree

[Ian Tickle]

> (*) ADP = Atomic Displacement Parameters

or "anisotropic displacement parameters"?

See http://ww1.iucr.org/comm/cnom/adp/finrepone/finrepone.html

Section 1.5 Comments about terminology

Cheers

-- Ian

Re: [ccp4bb] sudden drop in R/Rfree

[Ian Tickle]

> I'm aware of this document. Personally I prefer "ADP = Atomic Displacement
> Parameters" over anything ele, because, given that Atomic Displacement
> Parameters can be parameterized in many different ways, it makes it easier
> to operate with such terms like:
>
> - isotropic Atomic Displacement Parameters (isotropic ADP);
> - anisotropic Atomic Displacement Parameters (anisotropic ADP);
> - group Atomic Displacement Parameters (group ADP);
> - group isotropic Atomic Displacement Parameters (group isotropic ADP;
> example: when refining one isotropic ADP per set of selected atoms);
> - group anisotropic Atomic Displacement Parameters (group anisotropic ADP;
> example TLS);
> - ... etc, etc...
>
> (no intention to open another "can of worms" ! -:) )

Hi Pavel, but couldn't you simplify it further by omitting the word
"atomic" throughout?  In fact isn't "group (an)isotropic Atomic
Displacement Parameter" a contradiction in terms?  Surely it can be
either a group parameter or an atomic parameter but not both at the
same time?

I think the worms are already out and making good their escape :).

Cheers

-- Ian

Re: [ccp4bb] sudden drop in R/Rfree

[Ian Tickle]

On 2 March 2012 18:01, Jacob Keller  wrote:
> Can't there be a "group of atoms?"

For sure, but doesn't a given parameter either apply to a single atom
or to a group of atoms?

Cheers

-- Ian

Re: [ccp4bb] REFMAC Riding Hydrogens

[Ian Tickle]

> Pavel’s statement is likely a bit of an exaggeration, but he has a valid
> (yet hard to prove point). The default in CCP4i was (and is?) to use
> hydrogens only if present in the input file. This is IMO not a safe default.

I agree: what I find confusing here is that the current CCP4i default
is indeed to use H atoms only if present in input, whereas the current
documentation 
(http://www.ccp4.ac.uk/html/refmac5/keywords/restraints.html#makecif)
says (quoting verbatim):

HYDR [ Yes | No | All ] (Default HYDRogens All)
How to deal with the hydrogen atoms.
Y - if hydrogens are present in the input file, use them,
N - ignore hydrogens even if they are present in the input coordinate file,
A - add all hydrogens in their riding positions and use them for
geometry and structure factor calculations. They also contribute to
the gradient and second derivative matrix of geometry residual.

The documentation in this case also corresponds to the source code default:

  MAKE_HFLAG = 'A'

Which do we believe: GUI or source code?  Personally I'm much more
inclined to trust the defaults in the code over either the
documentation or the GUI, because I have a strong suspicion that the
CCP4i defaults (and yes even on occasions the documentation!) lag
somewhat behind the "community view" on this as represented by the
current code version.  Or is this an incorrect perception?

> Because there were some reporting errors in the past
> (http://proteincrystallography.org/ccp4bb/message18808.html) it is hard to
> tell from the PDB when refinement with hydrogens became hip. Discussions on
> this BB show that at the use of riding hydrogens is still not fully
> accepted, especially at low resolution (where they actually help most).

Documentation says: "For low resolution and early stages it is better
to use MAKE HYDR N, i.e. do not use hydrogens even if they are present
in the input file.".

Cheers

-- Ian

Re: [ccp4bb] Matthews coeff. from model

[Ian Tickle]

matthews_coef ?

-- Ian

On 12 March 2012 17:35, james09 pruza  wrote:
>
>
>
>> Dear CCP4bbers,
>>
>> Is there any tool to calculate the Matthews coefficient from a
>> crystallographic model of RNA-protein complex?
>>
>> Thanking you.
>> James.
>
>

Re: [ccp4bb] Matthews coeff. from model

[Ian Tickle]

... or rwcontents ?

-- Ian

On 12 March 2012 17:35, james09 pruza  wrote:
>
>
>
>> Dear CCP4bbers,
>>
>> Is there any tool to calculate the Matthews coefficient from a
>> crystallographic model of RNA-protein complex?
>>
>> Thanking you.
>> James.
>
>

Re: [ccp4bb] negative difference density around sulphur and oxygen atoms

[Ian Tickle]

Hi Chris

I would say there's something very wrong if you're seeing -6 sigma
difference peaks at O atoms.  I don't see how this can be explained by
radiation damage.  I for one have never seen that before in a
structure where there weren't other obvious issues (or maybe I just
haven't looked hard enough).

I would try refining it with a different program, e.g. Buster, or even
a different version of Refmac (I use 5.6.x routinely, but I see
there's a 5.7.x now - Garib will no doubt have an opinion on which is
the best one to use).  At least that will eliminate the software as
the origin of the problem: if it doesn't go away then we'll have to
think again.

Cheers

-- Ian

On 4 April 2012 16:16, Chris Meier  wrote:
> Dear all,
> I am refining the X-ray structure of a protein:
> Data to ~2A were collected at a latest-generation synchrotron.
> The 2fo-Fc maps are crisp, the model of the protein is complete and I am 
> reasonably happy with the stats (R below 20%, Rfree below 25% in Refmac 5.5).
> However, I am seeing a lot of negative difference density,
> especially around sulphur atoms (negative density around -9 sigma)
> and oxygen atoms (e.g. side-chain oxygens of Glu, Asp, etc. residues with 
> negative density around -6 sigma).
> Has anyone observed this before?
> I have found CCP4bb postings discussing radiation damange of suplphur atoms
> (e.g. http://www.dl.ac.uk/list-archive-public/ccp4bb/2004-07/msg00532.html ).
> Can this also happen with oxygen atoms?
> What would be an appropriate way to deal with this issue during refinement?
> Suggestions greatly appreciated.
> Thanks,
> Chris
>

Re: [ccp4bb] negative difference density around sulphur and oxygen atoms

[Ian Tickle]

PS you say the model is complete, but just as important how complete
is (are?) the data.

-- Ian

On 4 April 2012 16:16, Chris Meier  wrote:
> Dear all,
> I am refining the X-ray structure of a protein:
> Data to ~2A were collected at a latest-generation synchrotron.
> The 2fo-Fc maps are crisp, the model of the protein is complete and I am 
> reasonably happy with the stats (R below 20%, Rfree below 25% in Refmac 5.5).
> However, I am seeing a lot of negative difference density,
> especially around sulphur atoms (negative density around -9 sigma)
> and oxygen atoms (e.g. side-chain oxygens of Glu, Asp, etc. residues with 
> negative density around -6 sigma).
> Has anyone observed this before?
> I have found CCP4bb postings discussing radiation damange of suplphur atoms
> (e.g. http://www.dl.ac.uk/list-archive-public/ccp4bb/2004-07/msg00532.html ).
> Can this also happen with oxygen atoms?
> What would be an appropriate way to deal with this issue during refinement?
> Suggestions greatly appreciated.
> Thanks,
> Chris
>

Re: [ccp4bb] negative difference density around sulphur and oxygen atoms

[Ian Tickle]

The PNAS paper you refer to talks about a "loss of definition" of
exposed carboxyl O atoms, i.e. an increase in B factor, but presumably
if this is modelled properly then it shouldn't leave a big hole in the
difference map.  After all, the paper is not claiming that C-O bonds
are broken, only that there is "increased mobility" (or just as
likely, induced static disorder).  I'm wondering if this is related to
too-tight B-factor restraints.  I never use the default settings and
always use more relaxed ones: in particular I set the weights of B
factor restraints across angles to zero, IMO the across-bond
restraints are more than sufficient.  There has been a historical
obsession with getting B factors as low as possible (too-tight
restraints will certainly achieve this if that is your goal!), but
isn't the true goal of refinement to obtain the model which best
explains the data?

Cheers

-- Ian

On 4 April 2012 16:31, Roger Rowlett  wrote:
> PNAS 2000, 97, 623

Re: [ccp4bb] Refmac executables - win vs linux in RHEL VM

[Ian Tickle]

> I do not know whether this has recently been changed, but the license for
> icc-produced executables used to be rather restrictive. If I remember
> correctly, you were not allowed to distribute the binaries, full stop.

Nicholas, this restriction applies (and has always applied) only to
Intel's 'evaluation' licence: i.e. you get to try the Intel compilers
free for 1 month, but you're not allowed to redistribute any
executables you create with them.  I don't know if this means that the
software actually stops working after a month, I guess it does
-they're not as trusting as they used to be!

Intel's EULA for all their Software Development Products (including
all their compilers) states:

"Subject to all of the terms and conditions of this Agreement and any
specific restrictions which may appear in the Redistributables text
files, Intel grants to you a non-exclusive, non-assignable, fully-paid
copyright license to distribute (except if you received the Materials
under an Evaluation License as specified below) the Redistributables,
including any modifications pursuant to Section 2.B, or any portions
thereof, as part of the product or application you developed using the
Materials.".

I had our lawyers check this ~10 years ago when the compiler was at
version ~7 (it's now at 11), since we are commercial and wanted to
distribute our own sources & executables, and the conditions on
redistribution of user-created executables have not changed in essence
since then (obviously redistribution of the compiler executables
themselves has never been allowed).  What has changed is that the
licence conditions have become somewhat more restrictive in the sense
that academic institutional users are no longer eligible for free
licences! - though they do get a discount off the fully paid-up
commercial licence.  A personal non-commercial licence (which does not
cover use by academics) is still free.  In all cases (except
evaluation) executables can be freely distributed, along with any of
Intel's DLLs that are required to run it.

Please note that I have no financial interest in Intel ;).

Cheers

-- Ian

Re: [ccp4bb] Refmac executables - win vs linux in RHEL VM

[Ian Tickle]

> That's right. With a cost of $9,997.00 for a 3-years/2-seats academic
> license,
> I couldn't have been talking for anything else ... :-)))

Hi Nicholas

That sounds like way more than it should be, in fact it sounds like
you've been quoted the cost of the commercial licence and then some!
>From Intel's website the academic licence for icc (Linux/2 seats) is
$570 incl 1 year's support.  Renewal of support for subsequent years
will be less than this, probably around $250/year.  I have ifort + icc
(Linux/single user) & we paid about $1200 for the 1st year, and $500
for subsequent year's support.

Cheers

-- Ian