>>> Ian Tickle <ianj...@gmail.com> 05/30/20 7:14 AM >>>
>>(unless of course the completeness calculations were performed on two
different reflection files)?
EDS is in fact using a different dataset compared to the coordinates,
when I submit the output reflections.cif produced by phenix, when the
input I, sigma-I from a merged scalepack output (.sca) file.
Phenix copies the raw input data (I's) into the output file, and that is
what EDS uses.
Then phenix does French & Wilson conversion of I's to F's, and rejects
reflections with a low probability.
The resulting dataset is used in refinement, and the output statistics
are based on this.
For an example of the result, 6myo. From the validation report,Data and
refinement statistics:
Resolution (Å)
47.64 – 2.20 Depositor
80.48 – 2.20 EDS
% Data completeness (in resolution range)
91.1 (47.64-2.20) Depositor
86.2 (80.48-2.20) EDS
There were a few very low resolution reflections (probably behind the
beamstop)
in the .sca file, resulting in the low resolution seen by EDS. Phenix
rejects those
and reports the low-res cutoff 40 A But there are not a lot
of reflections between 40 and 80 A, so I think most of the difference is
due to F&W,
which EDS apparently does not apply.
I think this low-res cutoff is also responsible for the absurdly good
RSR-Z score for 6myo
compared to the ridiculously bad RSR-Z for otherwise very similar 6myp.
The ultra-low reflections aren't going to affect shape of the density
around individual residues. But RSR-Z is not a correlation, it depends
on the actual value of the (scaled) map, and that will be affected by
strong low-res reflections. So if RSR-Z is comparing a 2Fo-Fc map,
perhaps with fill-in, to an atom-map which effectively goes to
infinitely low resolution, data lacking those low-res reflections will
compare poorly, whereas data that is artificially extended to 80A with
fill-in will do much better.
(Still looking at this, may come back for advice later.)
Ed
>>> Ian Tickle <ianj...@gmail.com> 05/30/20 7:14 AM >>>
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 0 0.00 21.21 0.22
3 1 2 0.00 23.83 0.19
3 1 4 0.00 34.71 0.26
3 1 6 0.00 9.06 0.11
3 1 8 0.00 31.64 0.24
3 1 10 0.00 31.22 0.25
3 1 12 0.00 1.28 0.39
3 1 14 0.00 6.59 0.12
3 1 16 0.00 17.58 0.15
3 1 18 0.00 3.94 0.18
3 1 20 0.00 11.05 0.12
3 1 22 0.00 34.24 0.24
3 1 24 0.00 12.39 0.14
3 1 26 0.00 12.76 0.15
3 1 28 0.00 20.80 0.18
3 1 30 0.00 23.70 0.19
3 1 32 0.00 23.47 0.20
3 1 34 0.00 30.50 0.23
3 1 36 0.00 10.93 0.22
3 1 38 0.00 28.11 0.22
3 1 40 0.00 24.41 0.21
3 1 42 0.00 3 1 47 0.00 10.54 0.29
3 1 49 0.00 10.54 0.23
3 1 51 0.00 2.98 0.70
3 1 53 0.00 5.84 0.39
3 1 55 0.00 9.79 0.27
3 1 57 0.00 11.33 0.26
3 1 59 0.00 8.99 0.30
3 1 61 0.00 1.84 0.76
3 1 63 0.00 2.63 0.78
3 1 65 0.00 4.91 0.46
3 1 67 0.00 3.50 0.64
3 1 69 0.00 1.93 0.76
3 1 71 0.00 4.57 0.52
3 1 73 0.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
<robbie_joos...@hotmail.com> 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/
