Re: [ccp4bb] CCP4BB Digest - 28 May 2020 to 29 May 2020 (#2020-148)

[Jacqui Gulbis]

Ta

Now dear
My deadline for this grant is on the second
I will try to get a rewritten simplified version to you before tomorrow morning.
When I do PLEASE look it over and see if you can write in anything else wrt 
modelling - at present its not written in year 1
Also general check and approval
Thanks kid
jacq

On 30/5/20, 09:06, "CCP4 bulletin board on behalf of CCP4BB automatic digest 
system"  wrote:

There are 10 messages totaling 2125 lines in this issue.

Topics of the day:

  1. visual mask editor - why (2)
  2. Strange Pseudosymmetry Effects (2)
  3. Fwd: Refmac error (2)
  4. Job Offer at INNOVATION CAMPUS BERLIN in Computational Chemistry
  5. PDB file header lines... (3)



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

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

--

Date:Fri, 29 May 2020 00:02:11 -0700
From:Pavel Afonine 
Subject: Re: visual mask editor - why

Hi Bernhard,

"Like comparing these map regions, excluding

intrusion of a solvent mask, etc.":

You didn't say much about the context.. So I'd say Polder map approach
comes to mind first based on these keywords. Next is "map comparison" (
https://doi.org/10.1107/S1399004714016289).

If none of the above: what we (or you) are missing?

Pavel

On Thu, May 28, 2020 at 11:17 AM Bernhard Rupp 
wrote:

> Maybe I should explain an example: Say coot detects an unmodelled blob
> (maybe a ligand). Now, I would like to do
>
> a number of things without biasing towards a model. Like comparing these
> map regions, excluding
>
> intrusion of a solvent mask, etc.
>
>
>
> Now could coot for example just generate a mask around what it already
> knows are blobs?
>
> Possible useful items could be a solvent mask not including that regions,
> or a density map
>
> that includes only features with a certain boundary around that blob.
>
>
>
> I pilfered some kludges together from different sources, but let’s just
> say inelegant would be a compliment.
>
>
>
> Best, BR
>
> 
>
> Brief question: Does something like a visual density mask editor exist?
>
> Thx, 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/webadmin?SUBED1=CCP4BB=1
>



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

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/

--

Date:Fri, 29 May 2020 09:34:23 +0100
From:Harry Powell - CCP4BB 
Subject: Re: Strange Pseudosymmetry Effects

Hi Tim

You could send out an SOS to some of the other authors in the same issue, 
who might have kept a copy - several are “regular" posters on this forum, e.g.

Sacha Urzhumtsev
Gerard Kleywegt
Eleanor Dodson

There’s a good chance they’ll be stuck at home at the moment with plenty of 
time to search through old boxes…

Harry

> On 28 May 2020, at 21:04, Tim Gruene  wrote:
> Dear Eddie, dear all
>
> According to ftp://ftp.ccp4.ac.uk/ccp4/newsletter/jun_95/, this article
> appeare in Newsletter June 95. It is mentioned in the table of contents,
> "Correction on perfection: primary extinction correction in protein
> crystallography" by Polykarpov and Sawyer.
> Unfortunately, the article itself is not there
>
> Extinction is not the same as the dynamic effects that James mentioned,
> but this seems the closest match.
>
> Would anyone have a copy they can share with me?
>
> Thanks a lot!
>
> Best,
>
> Tim



To 

Re: [ccp4bb] Completeness question

[vincent Chaptal]

Hi,

also agreed, but actually doing it proved a lot more tricky than I 
initially thought.
For my last structure, which was very anisotropic, I deposited a mmcif 
containing 1/ the originial data, 2/the truncated data and 3/ the map. 
It proved impossible to create this file with the tools at hand, and 
thanks to the globalphasing team, they were able to write a script using 
autoproc to do this.
If this routine could be incorporated into the staraniso web site, I'm 
sure it would be very used and help the case described here.


All the best
Vincent

ps: I'll be happy to share my procedure if it is helpful to anyone.


Le 30/05/2020 à 17:17, Ian Tickle a écrit :


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

Cheers

-- Ian


On Sat, 30 May 2020 at 15:58, Robbie Joosten 
mailto:robbie_joos...@hotmail.com>> 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 mailto:eleanor.dod...@york.ac.uk>> 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
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=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=1




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



--

Vincent Chaptal, PhD

Director of GdR APPICOM

Drug Resistance and Membrane Proteins Lab


MMSB -UMR5086

7 passage du Vercors

69007 LYON

FRANCE

+33 4 37 65 29 01

http://www.appicom.cnrs.fr

http://mmsb.cnrs.fr/en/





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

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

Re: [ccp4bb] 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=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=1
>



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

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

Re: [ccp4bb] Completeness question

[Robbie Joosten]

I fully agree. Unfortunately, not everyone does that so cases like I described will keep appearing. Cheers,RobbieOn 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..eleanorOn 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=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=1

Re: [ccp4bb] Completeness question

[Eleanor Dodson]

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=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=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] Completeness question

[Edward Berry]

>>> Ian Tickle  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, 
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  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   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   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 

Re: [ccp4bb] Completeness question

[Robbie Joosten]

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

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=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] visual mask editor - why

[dusan turk]

Dear Bernand,

In MAIN embedded map algebra can probably vover all what you need. If you want 
to go along this path, please, let me know and I will help you.

best,
dusan


> On 30 May 2020, at 01:00, CCP4BB automatic digest system 
>  wrote:
> 
> 
> Date:Fri, 29 May 2020 00:02:11 -0700
> From:Pavel Afonine 
> Subject: Re: visual mask editor - why
> 
> Hi Bernhard,
> 
> "Like comparing these map regions, excluding
> 
> intrusion of a solvent mask, etc.":
> 
> You didn't say much about the context.. So I'd say Polder map approach
> comes to mind first based on these keywords. Next is "map comparison" (
> https://doi.org/10.1107/S1399004714016289).
> 
> If none of the above: what we (or you) are missing?
> 
> Pavel
> 
> On Thu, May 28, 2020 at 11:17 AM Bernhard Rupp 
> wrote:
> 
>> Maybe I should explain an example: Say coot detects an unmodelled blob
>> (maybe a ligand). Now, I would like to do
>> 
>> a number of things without biasing towards a model. Like comparing these
>> map regions, excluding
>> 
>> intrusion of a solvent mask, etc.
>> 
>> 
>> 
>> Now could coot for example just generate a mask around what it already
>> knows are blobs?
>> 
>> Possible useful items could be a solvent mask not including that regions,
>> or a density map
>> 
>> that includes only features with a certain boundary around that blob.
>> 
>> 
>> 
>> I pilfered some kludges together from different sources, but let’s just
>> say inelegant would be a compliment.
>> 
>> 
>> 
>> Best, BR
>> 
>> 
>> 
>> Brief question: Does something like a visual density mask editor exist?
>> 
>> Thx, 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/webadmin?SUBED1=CCP4BB=1
>> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> 
> 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/
> 
> --
> 
> Date:Fri, 29 May 2020 09:34:23 +0100
> From:Harry Powell - CCP4BB 
> Subject: Re: Strange Pseudosymmetry Effects
> 
> Hi Tim
> 
> You could send out an SOS to some of the other authors in the same issue, who 
> might have kept a copy - several are “regular" posters on this forum, e.g.  
> 
>   Sacha Urzhumtsev
>   Gerard Kleywegt
>   Eleanor Dodson
> 
> There’s a good chance they’ll be stuck at home at the moment with plenty of 
> time to search through old boxes…
> 
> Harry
> 
>> On 28 May 2020, at 21:04, Tim Gruene  wrote:
>> Dear Eddie, dear all
>> 
>> According to ftp://ftp.ccp4.ac.uk/ccp4/newsletter/jun_95/, this article
>> appeare in Newsletter June 95. It is mentioned in the table of contents,
>> "Correction on perfection: primary extinction correction in protein
>> crystallography" by Polykarpov and Sawyer.
>> Unfortunately, the article itself is not there
>> 
>> Extinction is not the same as the dynamic effects that James mentioned,
>> but this seems the closest match.
>> 
>> Would anyone have a copy they can share with me?
>> 
>> Thanks a lot!
>> 
>> Best,
>> 
>> Tim 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/
> 
> --
> 
> Date:Fri, 29 May 2020 10:49:03 +0100
> From:Eleanor Dodson 
> Subject: Re: visual mask editor - why
> 
> Wont mapmask do that?  Find the fraction coordinate of the blob extent then
> carve that section out of the map?
> Eleanor
> From documentation:
> 
> *XYZLIM [ASU] [CELL] [MATCH]  **Set the output
> map extent as `extend'. - are given in grid units or in fractional
> coordinates. It is possible to automatically extend to the CCP4 default
> asymmetric unit, or a whole unit cell, by specifying `XYZLIM ASU' or
> `XYZLIM CELL'. It is also possible to extend the map to match another map
> (given as MAPLIM) by specifiying `XYZLIM MATCH'. The default is to keep the
> extent of the input map.*
> 
> On Fri, 29 May 2020 at 08:03, Pavel Afonine  wrote:
> 
>> Hi 

[ccp4bb] Completeness question

[Robbie Joosten]

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