Hi Ian, > 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. This is a general problem with anisotropic truncation. 6rjy is an example of something else going on. What happens is that people report the ellipsoidal completeness, but when you import the reflection data from the PDB and add the missing reflections (because those are typically not deposited) with the CCP4 program complete you get a spherical dataset. If you now calculate the completeness it will be very low and inconsistent with the reported number. This is actually also a problem on the side of the PDB validation as EDS does a similar thing.
So what I want is a way to reproduce the reported completeness even when it is the ellipsoidal completeness. Not being able to do so would then be a clear indication that something else is going on like you see below. I suppose replacing complete with something that can add the missing ellipsoidal reflections would also solve the problem. If anything that would be even more elegant. Cheers, Robbie > > 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 11.04 0.21 > 3 1 44 0.00 12.58 0.28 > 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 <mailto: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 > <http://www.jiscmail.ac.uk/CCP4BB> , a mailing list hosted by > www.jiscmail.ac.uk <http://www.jiscmail.ac.uk> , terms & conditions are > available at https://www.jiscmail.ac.uk/policyandsecurity/ > ######################################################################## To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/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/
