Re: [ccp4bb] add ligand with AceDRG

[Gerard Bricogne]

Dear Oliver and CCP4BB readers,

This obsoleted LIG came from PDB entry 1JVP deposited in 2001 by Jean-Michel
Rondeau working at Novartis. He must simply have been the first person to
deposit a structure in which the ligand was called LIG ... . That molecule
is now called 89E, but as Phil showed, there are still remnants of its old
identity.

Best wishes,

Gerard.

--
On Fri, Apr 26, 2024 at 04:31:13PM +0100, Oliver Smart wrote:
> Hi Stefanie,
> 
> If you want to try Grade2 (for a non-confidential ligand) then this is easy 
> to do using the Grade Web Server
> 
> https://grade.globalphasing.org/
> 
> We have altered our default "3-letter code” (aka PDB chemical component ID) 
> to “LIG”. 
> The reserved PDB two letter codes 01 to 99 are also fine (as are INH and 
> DRG). 
> We  understand from users that Grade2 restraint dictionaries work well with 
> REFMAC (as to AceDG)
> Checking my installation of CCP4 8.0 there are no distributed dictionaries 
> for LIG, DRG or 01 to 99.
> 
> There was a PDB component LIG that was obsoleted in 2021 
> https://www.ebi.ac.uk/pdbe/static/files/pdbechem_v2/LIG.cif
> And there was a restraint dictionary for this distributed with CCP4 7.0.
> 
> Perhaps you are picking up things from an old CCP4 installation
> 
> Hope this helps,
> 
> Oliver 
> 
> 
> 
> 
> > On 26 Apr 2024, at 11:21, FREITAG-POHL, STEFANIE 
> >  wrote:
> > 
> > Dear all,
> > 
> > thank you so much for all your suggestions.
> > 
> > Unfortunately, nothing helped. Whatever 3-letter code I choose Refmac is 
> > complaining that there is a clash with an already existing ligand (even 
> > DRG, LIG, numbers) and AceDRG in CCP4i2 insists on 3 letters.
> > 
> > I am not quite sure how to bypass this issue as I think Refmac is also 
> > insisting on 3-letters for ligands (???)
> > 
> > I have not tried Grade yet.
> > 
> > Any advise much appreciated.
> > 
> > Best wishes,
> > Stefanie
> > 
> > 
> > 
> > Dr. Stefanie Freitag-Pohl (she/her)
> > Durham University
> > Department of Chemistry
> > South Road, Durham
> > DH1 3LE
> > United Kingdom
> > 0191 334 2596
> > stefanie.freitag-p...@durham.ac.uk 
> > 
> > From: CCP4 bulletin board  > > on behalf of FREITAG-POHL, STEFANIE 
> >  > >
> > Sent: 25 April 2024 13:01
> > To: CCP4BB@JISCMAIL.AC.UK  
> > mailto:CCP4BB@JISCMAIL.AC.UK>>
> > Subject: [ccp4bb] add ligand with AceDRG
> >  
> > [EXTERNAL EMAIL]
> > Hi all,
> > 
> > I have trouble adding a ligand with AceDRG in CCP4i2 into my refinement:
> > 
> > I put in a smilesstring and the ligand is written ok, but since I can only 
> > chose already 'taken' 3-letter-codes the refinement always crashes as there 
> > is a clash with existing library entries.
> > Is there any way around this? How do I add a novel ligand?
> > 
> > Thanks so much for your help.
> > 
> > Best wishes,
> > Stefanie
> > 
> > 
> > 
> > Dr. Stefanie Freitag-Pohl (she/her)
> > Durham University
> > Department of Chemistry
> > South Road, Durham
> > DH1 3LE
> > United Kingdom
> > 0191 334 2596
> > stefanie.freitag-p...@durham.ac.uk 
> > 
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> > 
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

[ccp4bb] Resumption of activity of the STARANISO server

[Gerard Bricogne]

Dear CCP4BB readers,

We are pleased to announce that the STARANISO server is available again at 
https://staraniso.globalphasing.org/ , with full functionality including
PDBpeep and Table1.

With best wishes,

Ian, Clemens, Claus & Gerard.



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

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

Re: [ccp4bb] Rwork and Rfree the same?

[Gerard Bricogne]

Dear Justin,

 Would it be possible for you to send off-list the report_staraniso.pdf
file created by your autoPROC job (or the job number of your STARANISO
submission if you used the server) so that we can examine the pattern of
data incompleteness indicated by the plots? 

 This would be a great help in deciding whether this incompleteness is
caused by a missing angular range or purely by anisotropy in the diffraction
limits. We would then know what kind of in-filling with Fcalc would occur
with what refinement program(s), with what consequences on the maps.

 Please send this file to "proc-deve...@globalphasing.com" . Thank you!


 With best wishes,

  Gerard.

--
On Wed, Feb 28, 2024 at 11:21:26AM -0500, Justin Cruite wrote:
> Thanks everyone,
> 
> I agree, 18.4% Rwork and Rfree is too good to be true for a 3.4 Å dataset.
> The data was processed using autoProc and the staranisano mtz was used for
> MR. The completeness is only 38%. It could be that the Rfree and Rwork
> reflection sets are small because of this? What is the best way to check
> the number of reflections used for Rwork and Rfree? Is this dataset usable
> at all?
> 
> Thanks!
> 
> Justin
> 
> On Wed, Feb 28, 2024 at 10:21 AM nicfoos  wrote:
> 
> > Hello Justin,
> >
> > There is something weird in your results. You mention Rwork/Rfree of
> > 0.1837.
> > This means a pretty good refinement and also is very unusual to be
> > obtain for a resolution of 3.37.
> > Additionally you should not have Rfree = Rwork.
> > I suspect something wrong with you Rfree reflections sets. What size is
> > it ? Is your dataset complet ?
> > How did you cut the res. ?
> >
> > I hope this may help you.
> >
> > Nicolas
> >
> >
> >
> > On 2024-02-28 16:10, Justin Cruite wrote:
> > > Hi everyone,
> > >
> > > What does it mean if your Rwork and Rfree are exactly the same?
> > >
> > > I solved a 3.37 Å structure with Phaser-MR and immediately ran 10
> > > cycles of refinement with wxc = 0.1. Everything else at default. The
> > > Rwork and Rfree are both 0.1837. Is this bad?
> > >
> > > Thank you!
> > >
> > > Justin
> > >
> > > -
> > >
> > > To unsubscribe from the CCP4BB list, click the following link:
> > > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> >
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] About Staraniso

[Gerard Bricogne]

Dear Vincent,

 Thank you for chipping in as you did, with so much useful feedback
about the difficulty of re-using PDB depositions containing anisotropic
data. It is a very useful picture of what is definitely a "bleeding edge" on
the "R" side of the wwPDB's "FAIR" ideal.

 It would be most helpful if you could share with us (off-line) the
details of the specific problems you encountered and that led to the odd
recommendation that you should use a text editor to combine the contents of
mmCIF files. 

 It is interesting that you used the turn of phrase "huge anisotropy
combined with lack of completeness in high resolution shells" as if they
were two distinct evils that had conspired to combine in order to make your
life difficult. In reality, as you are of course well aware, they are one
and the same evil, as strong anisotropy will necessarily result in low
completeness in the *spherical* shell to the highest diffraction limit. The
diagram at the beginning of the page 

 https://staraniso.globalphasing.org/anisotropy_about.html

makes this totally obvious. The only way to have full completeness in the
outermost (spherical) shell is to have isotropic diffraction. Forgive me for
perhaps belabouring something you are perfectly aware of, but it provided an
opportunity to push back against "isotropic thinking" that is still so
deeply ingrained in the collective worldview.


 With best wishes,

  Gerard.

--
On Fri, Feb 16, 2024 at 09:59:59AM +0100, vincent Chaptal wrote:
> Hi Clemens and all,
> 
> I've been following with a lot of interest of course, anisotropy has
> taken a lot of space in my membrane-protein crystallography life.
> I remember the many exchanges we've had with you and Global Phasing,
> as well as many other software developpers over the years.
> 
> I would like to chip in to give the point of view of a user
> struggling with it, and since 6r72 was mentioned and I'm the
> author...
> 
> 6r72 has been an epic battle experimentally, and afterwards with
> data processing as well. The huge anisotropy combined with lack of
> completeness in high resolution shells, and low resolution, made a
> cocktail for not so great electron density. But since this was all I
> got, I had to make something out of it. Since the quality of the
> data was what it was, I definitely wanted others to be able to
> re-investigate it with modern tools, or just see for themselves the
> map I had to make the choices in modelling.
> Remember, I asked for your help to combine all the data of the
> entry, and GlobalPhasing was very helpful to make the tool for this
> entry. I believe, this was the moment you created the deposition
> tool you mention below.
> 
> The fact that the data is not easily retrievable is my point here.
> Pavel knows about this entry as we've been exchanging about it. I
> completely share with him the difficulty to parse through PDB
> entries, having performed several statistical analysis of the PDB to
> search for the root cause of anisotropy in membrane proteins myself
> (https://pubmed.ncbi.nlm.nih.gov/36206830/).
> I encountered the same issue for a recent entry (8qq7, soon
> available I hope) where we tried to combine the same files. I
> vaguely remembered the deposition tool you mention but I couldn't
> locate it (sorry), so we engaged in a dialog with the PDB who made
> us use text editors to merge the files basically. On the top of my
> head, I think we labelled the blocks "original_data", "modified_SA".
> 
> A standardization of this deposition is basically what you all want,
> to perform all the different downstream analysis you want. This is
> not available at the moment. I've been going out of my way to
> combine the files, but it would have been much easier to just give
> the SA_modified file to the PDB. I thus encourage all of you
> software developpers, despite your different point of views, to
> design and agree on such a tool to be placed at OneDep.
> 
> To finish, in case you want to reprocess a high-anisotropy, large
> difference in high-resolution limits, and low resolution, I have the
> images available for 6r72, 2y5y, and 8qq7 (all of which have the
> structure factors with original data, maps and modified data).
> 
> All the best
> Vincent
> 
> Le 15/02/2024 à 19:25, Clemens Vonrhein a écrit :
> >L'adresse mail de l'expéditeur est extérieure :owner-ccp...@jiscmail.ac.uk   
> >En cas de doute : ne répondez pas, ne cliquez pas et signalez le message au 
> >Support Informatique
> >
> >
> >Dear Pavel & CCP4bb readers,
> >
> >On Wed, Feb 14, 2024 at 08:28:03PM -0800, Pavel Afonine wrote:
> >>What follows below is not very specific to the particular program
> >>(STAIRSANISO) nor the original questions, but nonetheless, I believe it is
> >>relevant.
> >Thanks for joining the discussion: always good to have different viewpoints
> >or opinions made visible - especially for less knowledgeable users and
> >readers of the CCP4bb.
> >
> >And apologies to anyone 

Re: [ccp4bb] About Staraniso

[Gerard Bricogne]

Dear Kay,

 I think I should add a few comments and annotations to your reply to
Arpita, as it was addressed not just to her but to the general readership of
the CCP4BB. This will involve introducing an extra level of interleaving,
which can get a bit unsightly but can hardly be avoided.

 Please see below.


On Mon, Feb 12, 2024 at 04:55:02PM +, Kay Diederichs wrote:
> Dear Arpita,
> 
> I'll try to answer below -
> 
> On Mon, 12 Feb 2024 13:57:28 +0530, Arpita Goswami  
> wrote:
> 
> >Dear all,
> >
> >Greetings to all! Apologies if the below query seems very naive!
> >
> >This is to query on the consensus to use Staraniso for pdb submission. We
> >have solved a structure previously at 2.3 A resolution. The same data
> >(after reindexing the diffraction images in autoPROC) and after
> >reprocessing by ellipsoidal scaling in Staraniso gave structure at ~2.16 A.
> >
> >The previously solved structure did not have significant anisotropy
> >according to Aimless, so anisotropic scaling was not performed that time.
> 
> Maybe different resolution cutoffs were used: previously the 
> data were cut a 2.3A (according to some rule, e.g. "cut at =2"), 
> now they are cut at ~2.16A (according to a different rule, e.g. "cut at 
> =1.5").
> 
> Alternatively, different programs were used for data processing, and for
> the processing by the one used previously, the rule said "you should cut at 
> 2.3A", and for the one used now, the same rule said "cut at ~2.16A".
> After all, different programs give different data!
> 
> Speaking of rules, there are different "schools of thought" concerning the 
> "best" or "correct" rule for finding the resolution cutoff. I don't want to 
> repeat 
> the arguments here. It is important to know that there exists an experimental 
> and practical way (called "paired refinement") to find a meaningful 
> resolution 
> cutoff, and this requires refinement of a model, and comparison of 
> (basically) 
> Rfree values. The CCP4 program for this purpose is called PAIREF.
> There is also a web server called PDB-REDO that does paired refinement with
> your data and model.

 Arpita may not have come across the arguments that you don't want to
repeat, so she may find it useful to peruse the following item in the CCP4BB
archive: 

   https://www.mail-archive.com/ccp4bb@jiscmail.ac.uk/msg54145.html

that provides a useful introduction to the content of your paragraph above.
In particular, her use of PAIREF as available from CCP4 or PDB-REDO would
give her a resolution cut-off as a *single* number: applying such a cut-off
would then get her back to the situation where either good data will be
discarded in the better-diffracting direction(s), or essentially pure noise
will be kept in the worse-diffracting one(s). So this would be a huge step
backward from the results she has been alluding to, where we happen to know
that the default STARANISO analysis shows that these tetragonal crystals
diffract to 2.526 A along a* and b*, and to 2.039 A along c*. Trusting
PAIREF to give a useful indication of a single-number resolution in this
situation would seem totally unrealistic.

 There has been a publication on the simultaneous use of PAIREF and
STARANISO, using verbatim (and without acknowledgement) the procedure that
was suggested in the archive e-mail cited above (paragraph starting with
"Quite the contrary:"), namely using datasets obtained by running STARANISO
with different cut-off values for the local average of I/sig(I) and applying
the PAIREF procedure to assess which one is the most appropriate, and then
taking the associated diffraction limits as being the *three* diffraction
limits of the dataset. This way, one preserves the benefits of the
anisotropy analysis and one simply tweaks the STARANISO cut-off threshold
around its default value (1.2) by specifying another value through a
command-line parameter provided for that purpose since the inception of the
program. The publication in question can be found at 

  https://journals.iucr.org/j/issues/2023/04/00/ap5049/index.html

The process of exploring different STARANISO thresholds is manually driven,
and none of the available versions of PAIREF offer that feature - so
directing Arpita towards them may not be to her advantage. Before investing
too much hope in this type of investigation, it should be noted that this
article concludes that 

 "Corrections for diffraction anisotropy using the STARANISO server [with a
 default cut-off of 1.2] and [its output] data dramatically improved the
 quality of the observed electron density maps. No differences were observed
 with the extension of data from [those obtained with a cut-off value of
 1.2] to [those obtained with a cut-off value of 0.5]".


> >The overall spherical completeness of Staraniso structure is low (~73%)
> >while Ellipsoidal completeness is ~94%. Parallel isotropic scaling gives
> >structure with 99.6% completeness (but 2.3 A resolution). The statistics (R
> >merge 

[ccp4bb] [pe...@leadszone.live: CCP4 Study Weekend-2024] (fwd)

[Gerard Bricogne]

Dear all,

 I just received this a moment ago, and it looks most suspicious. Can
any action be taken, other than warn people not to follow up?

 Best wishes,

Gerard

- Forwarded message from Pedro Noel  -

Date: Fri, 15 Dec 2023 13:13:19 +
From: Pedro Noel 
Subject: CCP4 Study Weekend-2024
To: "g...@globalphasing.com" 

Hi ,

Would you be interested in acquiring the attendees list of "CCP4 Study Weekend 
2024"



 Each record constitutes details such as: Company Name, URL, Contact Name, 
Title, Verified Email Addresses, Contact Number, Physical Address etc.



Let me know if your interest and I will revert back with pricing and other 
deliverables.


Regards,
Pedro Noel

- End forwarded message -



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

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

Re: [ccp4bb] Multi-lattice crystal data processing strategy for structure solution

[Gerard Bricogne]

Dear Devbrat,

 With the unit-cell geometry you have, namely a very long axis and two
much shorter ones, you have to be exceedingly careful about how the data are
collected, and in particular about the crystal orientation and image width.

 If the long axis can be brought close to being parallel to the rotation
axis - either because the crystal morphology tends to make this happen or
(better) because you can use a multi-axis goniometer to orient it that way -
the images will have rows of closely-spaced spots that should be resolvable
if the detector is placed far enough. If on the other hand the long axis is
at a large angle to the rotation axis, there will be image ranges where that
axis gets close to being parallel to the beam, so that the separation of
reflections along that long axis (in fact, along the short reciprocal axis)
will depends on their angular distance. Unless the image width is small
enough, there will be overlap of the spots for consecutive reflections along
that short reciprocal axis. Indexing diagnostics may then give an impression
that there is more than one lattice, but most of all, because two distinct
reflexions may overlap into a single spot, many integrated intensities will
be corrupted. 

 Perhaps this is not the case, but out of curiosity: what is the angular
width of your images?


 With best wishes,

  Gerard.

--
On Tue, Nov 14, 2023 at 09:25:30PM +0530, Devbrat Kumar wrote:
> Hello everyone,
> 
> The issue with the crystal is its multi-lattice nature; even the truncated
> protein, which has been crystallized, exhibits multi-lattice
> characteristics (detectable only after XRD).
> 
> I have multiple native and selenium datasets with similar unit cell
> parameters. (One axis is excessively long.) The XRD images were processed
> using XDS in the P2 spacegroup, with unit cell parameters as follows: a =
> 27.75 Å, b = 293.9 Å, c = 34.6 Å, and β = 113°. The XDS-processed data were
> integrated with the data reduction tool AIMLESS in the CCP4i2 suite. In
> CRANK2, the Estimation of Matthews coefficient (Program used: GCX)
> suggested the presence of monomer NCS with a solvent content of 63.6%. The
> FA estimation and substructure detection were performed by SHELXC, which
> detected a very weak signal below 3.4 Å. Substructure determination was
> carried out using SHELXD, yielding a maximum figure of merit of 27.8 after
> 640 trials and suggesting 11 atoms in the substructure with an occupancy of
> at least 25%. Phasing and substructure refinement were conducted using the
> BP3 program, resulting in an FOM of 0.2. During hand determination, the
> programs suggested combined DM (density modification) FOM and phasing CLD
> score for hand one as 6.0 and for hand two as 4.783375. The tool didn't
> choose the hand because the value is less than the threshold. Density
> modification with Fourier recycling suggests that the final FOM for hand
> one and hand two is 0.428 and 0.482, respectively, while REFMAC5 gives the
> R factor and Rfree factor as 0.4262 and 0.4912.
> 
> One of the MR templates (model with balbes) works(For MR, Identity with the
> PDB template is 21%), but R & Rfree are stuck at 33 & 37 for the 2.7
> Angstrom cut-off (the total resolution in the dataset is 2 Angstrom). The R
> & Rfree is not decreasing for the dataset. I have played with detector
> distances for spot resolution, but at one pHi the spots have merged as a
> single spot, while at 90 degrees will give us the streak of spots.
> 
> Looking forward to hearing from you regarding dataset processing ideas for
> multi-lattice crystals(Native & Se dataset) and structure solution strategy.
> 
> Thank you.
> Regards
> Devbrat
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Density at a short distance near Tyrosine

[Gerard Bricogne]

Dear Lumbini,

 Thank you for sharing this picture.

 Considering the low resolution and modest quality of your map, as
manifested in the "blobbiness" of the side chains near the green peak, the
"short distance" you mention is perhaps quite imprecise and thus not such a
barrier to tentatively placing a water molecule in that peak. What happens
if you do and re-refine?


 Best wishes,

Gerard

--
On Wed, Sep 06, 2023 at 06:42:03PM +0530, Lumbini Yadav wrote:
> Dear Matthew,
> Below is the jpeg attached  for the density at 4sigma.
> 
> On Wed, Sep 6, 2023 at 6:21 PM Matthew Snee 
> wrote:
> 
> > Is the density big enough for it to be phospho-tyrosine?
> >
> > Best wishes
> >
> > Matthew.
> > --
> > *From:* CCP4 bulletin board  on behalf of Lumbini
> > Yadav 
> > *Sent:* 06 September 2023 13:47
> > *To:* CCP4BB@JISCMAIL.AC.UK 
> > *Subject:* [ccp4bb] Density at a short distance near Tyrosine
> >
> > Hi all, I have determined the structure of a protein at 3Å resolution. The
> > protein has 6 chains in the asymmetric unit. In all these 6 chains I see a
> > density near tyrosine which is at a distance of 2. 1 from the OH group of
> > tyrosine. Since this
> > ZjQcmQRYFpfptBannerStart
> > This Message Is From a New External Sender
> > You have not previously corresponded with this sender. Please exercise
> > caution when opening links or attachments included in this message.
> >
> > ZjQcmQRYFpfptBannerEnd
> >
> > Hi all,
> >
> > I have determined the structure of a protein at 3Å resolution. The
> > protein has 6 chains in the asymmetric unit. In all these 6 chains I see a
> > density near tyrosine which is at a distance of 2.1 from the OH group of
> > tyrosine. Since this distance is short for a hydrogen bond we are skeptical
> > about adding water molecules at this position.  We have ruled out the
> > presence of a metal ion at that position.
> >
> > Any insight on what should be added in this density at this short distance
> > would be appreciated
> >
> > Thank you
> >
> >
> >
> > Regards
> >
> > Lumbini
> >
> > --
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> > [jiscmail.ac.uk]
> > 
> >
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] British X-ray Crystallographers

[Gerard Bricogne]

Dear Jon,

 Quite a line-up indeed.

 Might someone at the RSC correct the typo in Elspeth's surname (in two
places)? Or is it a plural form ;-) ?


 With best wishes,

  Gerard

--
On Tue, May 23, 2023 at 10:16:54PM +, Jon Cooper wrote:
> I am biased, but this looks like an interesting meeting:
> 
> https://www.rsc.org/events/detail/76719/british-x-ray-crystallographers
> 
> Best wishes, Jon Cooper.
> jon.b.coo...@protonmail.com
> 
> Sent with [Proton Mail](https://proton.me/) secure email.
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] happy/sad maps

[Gerard Bricogne]

Dear James,

 The questions of optimally combining oversampling, blurring and
de-blurring to obtain accurate approximations of Fourier transforms by
discrete Fourier transform calculations are old hat: they go back to papers
by David Sayre in 1951 ('The calculation of structure factors by Fourier
summation', Acta Cryst. 4, 362-367) and were dealt with in a landmark paper
by Lynn Ten Eyck in 1977 ('Efficient Structure-Factor Calculation for Large
Molecules by the Fast Fourier Transform', Acta Cryst. A33, 486-492) with a
follow-up by Jorge Navaza in 2002 ('On the computation of structure factors
by FFT techniques', Acta Cryst. (2002). A58, 568-573). All the ideas needed
to understand the phenomenon you describe (i.e. aliasing errors) are already
presented with remarkable clarity in David Sayre's paper.


 With best wishes,

  Gerard.

--
On Sun, Apr 30, 2023 at 02:15:54PM -0700, James Holton wrote:
> Thank you Paul.  This is interesting!
> 
> I have not played with super-sampling yet.  I am assuming you mean
> creating a new map 8x the size? If so, did you fill the interstitial
> grid with zeroes? Local maximum? Linear interpolation?  Tricubic
> spline?
> 
> And when you say "sharpen/blur" with a factor of 4. Is 4 a scale
> factor? or a B factor?
> 
> Cheers, and I hope you had a pleasant weekend,
> 
> -James
> 
> On 4/28/2023 5:29 PM, Paul Emsley wrote:
> >What fun!
> >
> >super-sampled by a factor of 2 then sharpen/blur with a factor of
> >4 gives a superposition
> >
> >Paul.
> >
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Structure prediction - waiting to happen

[Gerard Bricogne]

Dear all,

 I think that quoting general viewpoints and statements, however
knowledgeable and respected their authors may be, will only exacerbate the
climate of clashing prejudices between two camps and is bound to sustain a
war of opinions rather than lead to a rational acceptance that something has
changed. The frustration is that one camp (the AlphaFold believers) can be
viewed as in effect preventing experiments that could prove it wrong.

 One way to deal with this obstruction would be to provide, in each
particular case, evidence that the AlphaFold results "do not cut it" as the
sole provider of 3D information within the project at hand. This means that
every grant proposal requesting resources towards a crystallographic
structure solution should document the fact that AlphaFold predictions have
been performed (or, often, looked up in a database of pre-cooked results)
but do not provide the accuracy required for the proposed investigation. If
this step of writing up the "Background" section of the grant actually
delivers a useful result, then everyone will be happy; and if it doesn't,
then the case for the need to allocate resources to solving the structure by
crystallography will be unassailable. In this way, AlphaFold will be a game
changer (we have known that since July 2021) but not a game killer. Savvas
alluded to a similar approach, but it could be made a formal requirement
acceptable to both proposers and reviewers, who would then both be dealing
with the situation in a scientific rather than dogmatic manner.


 With best wishes,

  Gerard.

--
On Sat, Apr 01, 2023 at 06:54:33PM +, Goldman, Adrian wrote:
> I think this is all true - and I’ve been putting things like this into my 
> (failing) grants - but I get the dispiriting sense that the medics think (to 
> borrow a line from hamlet) “the applicant doth protest too much methinks”. 
> 
> Well if as per James H today ;), we deposit coordinates to 1sf, alphafold 
> will be just fine. 
> 
> Of course the coordinates won’t be of any use to anybody, but the pictures 
> will be nice. 
> 
> Adrian 
> 
> Sent from my iPhone
> 
> > On 1 Apr 2023, at 21:39, Randy John Read  wrote:
> > 
> > There’s also this preprint with Tom Terwilliger as lead author: 
> > https://www.biorxiv.org/content/10.1101/2022.11.21.517405v1. The title is 
> > “AlphaFold predictions: great hypotheses but no match for experiment”.
> > 
> > Best wishes,
> > 
> > Randy
> > 
> >> On 1 Apr 2023, at 18:18, Savvas Savvides 
> >> <9d24f7f13e09-dmarc-requ...@jiscmail.ac.uk> wrote:
> >> 
> >> Dear Rams,
> >> 
> >> I salute you for sharing this.
> >> 
> >> Just a week ago, I also received a remark along these lines on a declined 
> >> grant application. The remark was the only unfavourable point, which 
> >> suggested that it must have weighed disproportionally towards the negative 
> >> outcome. This was a two-stage evaluation process and the grant was cut in 
> >> stage-1 where it was evaluated by a small group of evaluators, none of 
> >> whom was a structural biologist/biochemist. Stage-2 would have involved 
> >> peer review by international experts.
> >> 
> >> Despite my initial disbelief about what this remark might have caused and 
> >> upon reflection, I realized that it might be time to become proactive in 
> >> future applications in anticipation of the apparent growing trend towards 
> >> such remarks and perceptions.
> >> 
> >> I think that a generalized form of preemptive text might not serve the 
> >> purpose well, but perhaps well-articulated statements specific to the 
> >> proposed biological problem at hand (perhaps aided by illustrations 
> >> demonstrating the inability of structure prediction to address the problem 
> >> at hand) might be the better way to go. Even though many of us who teach 
> >> courses in experimental structural biology and structural bioinformatics 
> >> at undergraduate and graduate levels are already actively addressing many 
> >> of these issues, there is a much bigger and far more senior scientific 
> >> population out there that makes important decisions on science 
> >> policy/funding/infrastructures/evaluations/recruitment/etc that are not 
> >> getting such educational exposure.
> >> 
> >> The following resources provide good material and starting points to 
> >> reflect and elaborate upon.
> >> 
> >> The article by Perrakis and Sixma in EMBO Reports 
> >> https://www.embopress.org/doi/full/10.15252/embr.202154046
> >> 
> >> The recent comment paper in Nature Methods by Thomas Jane
> >> https://doi.org/10.1038/s41592-022-01760-4 
> >> 
> >> A correspondence in Science by Moore, Hendrickson, Henderson and Brunger
> >> https://www.science.org/doi/10.1126/science.abn9422?url_ver=Z39.88-2003_id=ori:rid:crossref.org_dat=cr_pub%20%200pubmed
> >> 
> >> 
> >> Best wishes
> >> Savvas
> >> 
> >> 
> >> 
> >> Savvas Savvides
> >> VIB Center for Inflammation Research
> >> Ghent University, Dept. of Biochemistry & 

Re: [ccp4bb] IUCr in 2023

[Gerard Bricogne]

Sorry ... IUCr2023 of course ... .

--
On Wed, Nov 23, 2022 at 09:36:35AM +, Gerard Bricogne wrote:
> Dear Tom,
> 
>  Thank you for this most welcome news! The previous deadline was *nine
> months* before the start of the meeting, that really didn't make sense. For
> the last "normal" meeting in 2017, it had been February 28th, i.e. *six*
> months ahead.
> 
>  It rather looked like the Event Organiser tail wagging the IUCr2203
> Congress dog :-) [1] .
> 
> 
>  With best wishes,
> 
>   Gerard.
> 
> 
> [1] For readers unfamiliar with English idioms:
> 
> https://dictionary.cambridge.org/dictionary/english/tail-wagging-the-dog
> 
> --
> On Wed, Nov 23, 2022 at 04:29:03AM +, Tom Peat wrote:
> > Hello All,
> > 
> > Some of you may have noticed that the deadline for abstract submission for 
> > the IUCr meeting in Melbourne, Australia passed just recently. There are 
> > reasons for the early deadline, but please forgive us for that. There is an 
> > extension/ second call for abstracts which will be advertised in the near 
> > future. In the meantime, the portal is still open and you are welcomed and 
> > encouraged to continue to submit and register for this conference (where we 
> > hope to see many of you).
> > 
> > This link should work to get you there: 
> > https://icmsaust.eventsair.com/iucr-2023/portal-2
> > 
> > Best regards, Tom
> > 
> > 
> > 
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> > 
> > This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> > list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> > https://www.jiscmail.ac.uk/policyandsecurity/
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] IUCr in 2023

[Gerard Bricogne]

Dear Tom,

 Thank you for this most welcome news! The previous deadline was *nine
months* before the start of the meeting, that really didn't make sense. For
the last "normal" meeting in 2017, it had been February 28th, i.e. *six*
months ahead.

 It rather looked like the Event Organiser tail wagging the IUCr2203
Congress dog :-) [1] .


 With best wishes,

  Gerard.
  

[1] For readers unfamiliar with English idioms:

https://dictionary.cambridge.org/dictionary/english/tail-wagging-the-dog

--
On Wed, Nov 23, 2022 at 04:29:03AM +, Tom Peat wrote:
> Hello All,
> 
> Some of you may have noticed that the deadline for abstract submission for 
> the IUCr meeting in Melbourne, Australia passed just recently. There are 
> reasons for the early deadline, but please forgive us for that. There is an 
> extension/ second call for abstracts which will be advertised in the near 
> future. In the meantime, the portal is still open and you are welcomed and 
> encouraged to continue to submit and register for this conference (where we 
> hope to see many of you).
> 
> This link should work to get you there: 
> https://icmsaust.eventsair.com/iucr-2023/portal-2
> 
> Best regards, Tom
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] PAIREF, Anisotropy and STARANISO

[Gerard Bricogne]

Dear Kay,

 Thank you for your reply to our message. 

 Your "few remarks" actually raise a considerable number of interrelated
matters that need to be considered in their totality rather than piecemeal,
so this reply will necessarily be rather lengthy. 

 It was in any case our purpose in creating this separate thread to
bring all these matters under simultaneous scrutiny, as we felt previous
posts were alluding to subsets of them without really dealing fully with
their interrelatedness.

 The double interleaving of our respective contributions to this thread
may be inelegant, but hopefully will not be confusing. 


On Thu, Oct 06, 2022 at 11:32:35AM +0100, Kay Diederichs wrote:
> Dear Gerard,
> 
> I'm not going to comment on what others said in this (new) thread; just 
> trying to make a few remarks about what you write below - 
> 
> On Tue, 4 Oct 2022 17:01:10 +0100, Gerard Bricogne  
> wrote:
> 
> >Dear all,
> >
> > First of all, apologies for breaking the threads entitled "PAIREF -
> >Warning - not enough free reflections in resolution bin" and "Anisotropy" by
> >merging them into a new one, but it somehow felt rather against nature to
> >keep them separate.
> >
> > Since the early days of the availability of STARANISO [1] (the actual
> >starting year for the Web server [2] was 2016), we had a hunch that much of
> >what was happening in the PAIREF procedure might simply be the detection of
> >the existence of significant data beyond an initially chosen resolution
> >cut-off not only as a result of an excessively conservative criterion having
> >been applied in that initial choice, but as a consequence of anisotropy in
> >the data. 

> Why "much of what was happening ... as a consequence of anisotropy"? These
> words imply that datasets where PAIREF indicates "existence of significant
> data beyond an initially chosen resolution cut-off" (EOSDBAICRC) are
> anisotropic, but that is a) not the case, because PAIREF - or paired
> refinement in general - in my experience, and that of others, often
> indicates EOSDBAICRC also for isotropic data, b) this depends on the
> initial cutoff. So your general statement (or hunch?) cannot be correct.

 We do not see such an implication, but rather the reverse: these words
state that when data are anisotropic (according to the context established
by the Subject line of this thread), PAIREF is likely to suggest a higher
resolution cut-off than would typically have been chosen initially, for the
simple reason given in our paragraph immediately below - i.e the idea that
such an initial choice would have been a "compromise", or intermediate,
isotropic cut-off between the lowest and highest diffraction limits. Perhaps
that paragraph is worth re-reading :

> > The latter would give rise to different diffraction limits in
> >different directions, and the choice of a single value for "the resolution"
> >at which the data were cut off would necessarily yield a compromise value
> >between the best and the worse diffraction limits. This would imply that
> >significant data would be excluded in the best diffracting directions, that
> >would subsequently drive PAIREF towards increasing the estimated resolution
> >compared to its compromise value.

 This viewpoint was self-evident to us at the time we were starting the
work on STARANISO because we constantly had in mind the fundamental picture 

https://staraniso.globalphasing.org/anisocut.png

(referred to as "The Picture" in the rest of this message) that ended up
being incorporated into the documentation on the server at 

   https://staraniso.globalphasing.org/anisotropy_about.html

(it would be very useful to keep that picture displayed at all times while
reading this message).

Regarding your point (a), therefore: we did write that this "hunch" referred
to a situation where the data would be anisotropic - this is what "much of"
was meant to subsume. Regarding point (b), the picture and the "compromise"
nature of typical cut-off choices reconcile your statement with ours. For
isotropic data we would not dispute that PAIREF might be able to detect that
an initial cut-off might have been too conservative.


> In its current implementation, PAIREF tries to determine the isotropic
> resolution cutoff that gives the best model based on valid comparisons of
> (mainly) Rfree values (it also gives other information to the user). 

 To keep this discussion as focussed as possible, we thought we would
try and stick to the rules of the BBC Radio4 talk show "Just a minute" and
to write about our subject "without hesitation, deviation or repetition".
This is notoriously

Re: [ccp4bb] PAIREF, Anisotropy and STARANISO -- a small correction

[Gerard Bricogne]

Dear Petr and CCP4BB readers,

 A lapse of attention led to a possibly obscure sentence: in the first
paragraph of our answer, the sentence "The input reflections to STARANISO
that are not present ..." should, for the avoidance of doubt, read: "The
input reflections to STARANISO that are not present in its output ...". 

 Apologies for the near-duplication of the same message.


 With best wishes,

Clemens, Claus, Ian & Gerard

--
On Wed, Oct 05, 2022 at 04:20:15PM +0100, Gerard Bricogne wrote:
> Dear Petr,
> 
>  Thank you for your reply and for inviting us to address some points!
> Please find our replies below, "interleaved" with your questions.
> 
> 
> On Tue, Oct 04, 2022 at 04:41:58PM +, Petr Kolenko wrote:
> > Dear Gerard,
> > A great remark! Thank you for starting this thread separately. I think
> > that you are absolutely right in many of the points. However, it also
> > raises several questions. Here are my favourite ones:
>  
> > 1) If STARANISO generally suggests "the same" resolution as PAIREF, there
> > are fewer reflection in the final dataset because of the ellipsoidal cut
> > in the worst diffraction direction. Is it good to avoid these data? 
> 
>  Your are right that the STARANISO output contains fewer reflections,
> but what is a "reflection" in this context, other than a triplet of Miller
> indices with a few numbers associated with it? The latter do not necessarily
> qualify as "data". This is the essential point that is made in the STARANISO
> documentation, found at
> 
>   https://staraniso.globalphasing.org/anisotropy_about.html
> and   https://staraniso.globalphasing.org/staraniso_glossary.html ,
> 
> where a distinction is made between *measurements* (just the same as what
> you call a "reflection": an HKL triplet, with values for I and sig(I)) and
> *observations*, defined as measurements deemed (according to a certain
> criterion) to contain information and not just noise. STARANISO takes great
> care in using a criterion that is based not on the I and sig(I) of
> individual reflections, but on a local average of I/sig(I) that detects a
> trend rather than just point-wise values, so as to retain weak reflections
> that occur surrounded by stronger neighbouring ones, and whose weakness
> conveys information. The input reflections to STARANISO that are not present
> are those that do not qualify as observations according to that criterion,
> and therefore contain only noise. You ask: "Is it good to avoid these
> data?": our answer is that the reflections not carried through by STARANISO
> are not data but noise, so that avoiding them not only does not lose
> information but eliminates noise. We justify this by disagreeing with the
> widespread belief, voiced by Eleanor, that noisy measurements cannot harm
> refinement if properly weighted, and pointing out that such measurements are
> *toxic* in a variety of ways - not least, in the case of anisotropic data,
> by biasing all sorts of statistics, or error-model parametrisations, that
> assume isotropic distributions of errors or compute certain estimators in
> spherical "bins".
> 
>  A minor point about terminology here: STARANISO does not apply an
> "ellipsoidal cut-off". It determines an anisotropic cut-off surface that is
> not constrained to being an ellipsoid (it is displayed as it comes in one of
> the panels in the Reciprocal Lattice Viewer). An ellipsoid that gives the
> best fit to that surface is then determined, but is used only in calculating
> the diffraction limits in its three principal directions. The cut-off
> applied is based on the surface itself, not on that best-fitting ellipsoid.
> 
> 
> > 2) A very general one: Are we doing well when touching the experimental
> > data with anisotropic scaling? Should we rather modify the model to fit
> > the "raw" data? If so, how about to do it? I may be wrong, but would it be
> > possible to refine the structure using all-atom based general anisotropic
> > ADP (similar to TLS refinement)?
> 
>  One could indeed limit the treatment of anisotropy to the determination
> and enforcement of the cut-off surface, leaving the data with its original
> decay pattern. Refining against such data would yield a model whose
> corresponding electron density map would reflect the anisotropy of the data,
> i.e. would be blurred differently in different directions. This is what
> Michael Sawaya described in
> 
>  https://www.pnas.org/doi/full/10.1073/pnas.0602606103
> 
> but found unsatisfactory when it came to the interpretability of 2Fo-Fc maps
> produced in these conditi

Re: [ccp4bb] PAIREF, Anisotropy and STARANISO

[Gerard Bricogne]

estrained in PAIREF, there
> is no improvement anymore.

 The entry in the PDB for BO (6I3J) seems to have undergone a number of 
revisions, one of them being a carbohydrate remediation. Reprocessing the
raw images with autoPROC/STARANISO indicated diffraction limits of (2.31A,
2.43A, 2.56A) along (a*,b*,c*). Examination of these images shows spot
shapes indicating a possibly cracked crystal; the 0.5-degree image width,
with two unit-cell axis lengths above 200A, could cause worries about
possible angular overlaps, but the F-centering probably saved the game. We
should perhaps follow up separately about this particular dataset, but the
general suggestion we would make is that, when conducting investigations on
such matters as the benefits of PAIREF, it would be advisable to either use
a much larger number of datasets, or, if using only a few as was done in
your paper, to carefully vet them, so as to minimise possible interference
from raw data peculiarities.


     With best wishes,

Clemens, Claus, Ian and Gerard.


> 
> From: CCP4 bulletin board  on behalf of Gerard 
> Bricogne 
> Sent: Tuesday, October 4, 2022 6:01:10 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] PAIREF, Anisotropy and STARANISO
> 
> Dear all,
> 
>  First of all, apologies for breaking the threads entitled "PAIREF -
> Warning - not enough free reflections in resolution bin" and "Anisotropy" by
> merging them into a new one, but it somehow felt rather against nature to
> keep them separate.
> 
>  Since the early days of the availability of STARANISO [1] (the actual
> starting year for the Web server [2] was 2016), we had a hunch that much of
> what was happening in the PAIREF procedure might simply be the detection of
> the existence of significant data beyond an initially chosen resolution
> cut-off not only as a result of an excessively conservative criterion having
> been applied in that initial choice, but as a consequence of anisotropy in
> the data. The latter would give rise to different diffraction limits in
> different directions, and the choice of a single value for "the resolution"
> at which the data were cut off would necessarily yield a compromise value
> between the best and the worse diffraction limits. This would imply that
> significant data would be excluded in the best diffracting directions, that
> would subsequently drive PAIREF towards increasing the estimated resolution
> compared to its compromise value.
> 
>  This "hunch" was validated by a detailed comparison carried out on the
> exact same examples that are considered in the 2020 paper by Maly et al.,
> that is summarised in the attached PDF. In other words, whenever anisotropy
> is present in the data, PAIREF will tend to indicate a higher value for an
> isotropic cut-off than would have been estimated for the initial dataset.
> The problem with taking the PAIREF result as the final answer is that the
> higher cut-off it indicates is applied *isotropically*. The inclusion of the
> significant data thus reclaimed is therefore unavoidably accompanied by that
> of noisy data in the worst diffracting direction(s), resulting in alarmingly
> poor statistics in the outermost shell (as pointed out in Eleanor's message)
> that may cast doubts on the usefulness of the procedure. This consideration
> was the basis of the rationale for implementing an *anisotropic* cut-off
> surface in STARANISO, so that one could thus reclaim the significant data in
> the best-diffracting direction(s) while avoiding the simultaneous inclusion
> of the pure-noise measurements in the worse one(s). While this is clearly
> and extensively explained in the documentation provided on the STARANISO
> server [2], it seems to be far from having been assimilated. Of course this
> would be perfect material for a publication, but life is somehow too short,
> and our to-do list has remained too long, to leave us room for spending the
> necessary time to go through the process of putting a paper together. The
> truly important matter is to get our picture in front of the user community.
> 
>  Now that the combined topics of PAIREF and anisotropy are being brought
> to the foreground of the community's attention, this seems like the perfect
> opportunity to present our analysis and position: what PAIREF achieves in
> terms of an upward revision of an initial isotropic resolution cut-off is
> likely to be achieved more straightforwardly by submitting the same data to
> the STARANISO server (or using it within autoPROC [3]); and the STARANISO
> output will have the advantage of being devoid of the large extra amount of
> purely noisy, uninformative data that are retained in the output from PAIREF
> according to its revised 

[ccp4bb] PAIREF, Anisotropy and STARANISO

[Gerard Bricogne]

Dear all,

 First of all, apologies for breaking the threads entitled "PAIREF -
Warning - not enough free reflections in resolution bin" and "Anisotropy" by
merging them into a new one, but it somehow felt rather against nature to
keep them separate.

 Since the early days of the availability of STARANISO [1] (the actual
starting year for the Web server [2] was 2016), we had a hunch that much of
what was happening in the PAIREF procedure might simply be the detection of
the existence of significant data beyond an initially chosen resolution
cut-off not only as a result of an excessively conservative criterion having
been applied in that initial choice, but as a consequence of anisotropy in
the data. The latter would give rise to different diffraction limits in
different directions, and the choice of a single value for "the resolution"
at which the data were cut off would necessarily yield a compromise value
between the best and the worse diffraction limits. This would imply that
significant data would be excluded in the best diffracting directions, that
would subsequently drive PAIREF towards increasing the estimated resolution
compared to its compromise value.

 This "hunch" was validated by a detailed comparison carried out on the
exact same examples that are considered in the 2020 paper by Maly et al.,
that is summarised in the attached PDF. In other words, whenever anisotropy
is present in the data, PAIREF will tend to indicate a higher value for an
isotropic cut-off than would have been estimated for the initial dataset.
The problem with taking the PAIREF result as the final answer is that the
higher cut-off it indicates is applied *isotropically*. The inclusion of the
significant data thus reclaimed is therefore unavoidably accompanied by that
of noisy data in the worst diffracting direction(s), resulting in alarmingly
poor statistics in the outermost shell (as pointed out in Eleanor's message)
that may cast doubts on the usefulness of the procedure. This consideration
was the basis of the rationale for implementing an *anisotropic* cut-off
surface in STARANISO, so that one could thus reclaim the significant data in
the best-diffracting direction(s) while avoiding the simultaneous inclusion
of the pure-noise measurements in the worse one(s). While this is clearly
and extensively explained in the documentation provided on the STARANISO
server [2], it seems to be far from having been assimilated. Of course this
would be perfect material for a publication, but life is somehow too short,
and our to-do list has remained too long, to leave us room for spending the
necessary time to go through the process of putting a paper together. The
truly important matter is to get our picture in front of the user community.

 Now that the combined topics of PAIREF and anisotropy are being brought
to the foreground of the community's attention, this seems like the perfect
opportunity to present our analysis and position: what PAIREF achieves in
terms of an upward revision of an initial isotropic resolution cut-off is
likely to be achieved more straightforwardly by submitting the same data to
the STARANISO server (or using it within autoPROC [3]); and the STARANISO
output will have the advantage of being devoid of the large extra amount of
purely noisy, uninformative data that are retained in the output from PAIREF
according to its revised isotropic cut-off.

 We would very much welcome feedback on this position: indeed we would
like to *crowd-source* the validation (or refutation) of this conclusion. In
our view, continuing to use the PAIREF procedure to revise an isotropic
resolution cut off misses the point about the consequences of anisotropy.
The only sensible use of a PAIREF-like procedure would be to adjust the
cut-off threshold for the local average of I/sig(I) in STARANISO, whose
default value is currently 1.2 but can be reset by the user through the Web
server's GUI. We occasionally see datasets of very high quality for which
the CC_1/2 value in the outermost shell stays above 0.6 or even 0.7, and it
is quite plausible that further useful data could be rescued if the local
I/sig(I) cut-off threshold were lowered below 1.2.

 Concerning Eleanor's view that noisy data can't hurt refinement because
they are properly down-weighted by the consideration of e.g. Rfree values in
resolution shells, we would point out that any criterion based on statistics
in resolution shells will be polluted if the data are anisotropic and if the
noisy data that STARANISO would reject are retained. That will result in
excessive down-weighting of the significant data that STARANISO retains,
hence in losing the information they contain. Perhaps this is a matter for
later discussion, but the main idea is that retaining pure-noise data is not
neutral in refinement, and that every "isotropic thinking habit" on which
many views are based needs to be revisited.


 With best wishes,

Clemens, Claus, Ian and 

Re: [ccp4bb] Lower b-factors with increasing T

[Gerard Bricogne]

In a similar vein, there could be effects of variation in humidity. How is
humidity controlled at these different temperatures? It can drastically
affect crystal ordering, which is of course a key determinant of the
eventual Wilson B of a dataset and should be distinguished from a property
of the individual atoms when interpreting their refined B-factors.

Gerard.

--
On Thu, Sep 08, 2022 at 08:11:08AM +0200, Jan Dohnalek wrote:
> There could be a release of sum stress in the crystal with increasing
> temperature which could even lead to better ordering I can imagine.
> But that would need a very close inspection and mainly - are the structures
> completely isomorphous?? I.e. are there changes at all?
> 
> If not then I am puzzled.
> 
> Jan
> 
> 
> On Thu, Sep 8, 2022 at 3:03 AM Tom Peat  wrote:
> 
> > I think the basic question being asked is why are the B-factors going the
> > 'wrong' way?
> > That is, as the temperature increases, one might expect higher B-factors
> > (at least that is what we are taught) whereas what Matt is seeing is the
> > opposite- decreasing B-factors as one goes up in temperature (which I also
> > think is a little strange and I don't have an explanation).
> > cheers, tom
> > --
> > *From:* CCP4 bulletin board  on behalf of Phoebe
> > A. Rice 
> > *Sent:* Thursday, September 8, 2022 10:48 AM
> > *To:* CCP4BB@JISCMAIL.AC.UK 
> > *Subject:* Re: [ccp4bb] Lower b-factors with increasing T
> >
> >
> > I guess the big question is what is the question that you’re trying to
> > address from those numbers?   I’d be nervous about making conclusions about
> > trends in B factors from just 1 data set per temperature.  As you probably
> > know, the B factors will reflect static differences in atomic position
> > across asymmetric units as well as thermal motion, and it can be difficult
> > to control variables such as exactly how fast a crystal freezes or how much
> > trauma it experiences in its journey from sitting happily in a drop to the
> > frozen state.
> >
> >
> >
> > *From: *CCP4 bulletin board  on behalf of Matt
> > McLeod 
> > *Date: *Wednesday, September 7, 2022 at 1:57 PM
> > *To: *CCP4BB@JISCMAIL.AC.UK 
> > *Subject: *[ccp4bb] Lower b-factors with increasing T
> >
> > Hi everyone,
> >
> > I have a series of datasets at 253K (~2.0A), 273K (2.0A), 293K (2.0A),
> > 313K (2.2A) and I am curious as to the details in determining B-factors.
> >
> > I have treated these datasets more-or-less identically for comparison's
> > sake.  I used DIALS to index, integrate, and scale the data.  I scaled the
> > data to a ~0.6 CC1/2 cutoff.
> >
> > After fully refining the datasets, there is an odd trend with respect to
> > temperature (from what has been previously published) and I assume that
> > this is because of "behind-the-scenes" computation rather than a
> > biophysical observation.  The B-factors slightly decrease from 252-293K,
> > and then significantly drop at 313K.  The maps look pretty well identical
> > across the datasets.
> >
> > 253K - 53.8 A^2
> > 273K - 48.4 A^2
> > 293K - 45.5 A^2
> > 313K - 18.6 A^2
> >
> > I compared the wilson intensity plots from DIALS scaling for 273K and 313K
> > and they are very comparable.
> >
> > I am looking for suggestions as to where to look at how these b-factors
> > are selected or how to validate that these B-factor are or are not
> > accurate.  Also, any relevant literature would be welcomed.  From what I
> > have read, there is a general trend that as T increase, the atoms have more
> > thermal energy which raises the b-factors and this trend is universal when
> > comparing datasets from different temperatures.
> >
> > Thank you and happy to supply more information if that is helpful,
> > Matt
> >
> > 
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> >
> > This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> > mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
> > available at https://www.jiscmail.ac.uk/policyandsecurity/
> >
> > --
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> >
> > --
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> >
> 
> 
> -- 
> Jan Dohnalek, Ph.D
> Institute of Biotechnology
> Academy of Sciences of the Czech Republic
> Biocev
> Prumyslova 595
> 252 50 Vestec near Prague
> Czech Republic
> 
> Tel. +420 325 873 758
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of 

Re: [ccp4bb] Negative density

[Gerard Bricogne]

Dear Renu,

 Bernhard is probably on the right track. It is likely that your crystal
diffracted to substantially higher resolution than 1.7A, and that its
diffraction was sharply truncated by the edges of a detector placed too far.
If so, the sharp truncation in reciprocal space of the Fourier coefficients
going into your map calculation will cause "series termination" ripples in
your map in real space, that may well be the cause of what you see. 

 Remember that the average electron density in the unit cell is zero, so
that all the positive density visible as the chemically interpretable
features of the map is necessarily offset by negative density elsewhere,
although usually not sharply peaked.

 Can you share one of your diffraction images? If not, you could process
your dataset with autoPROC [1]: the STARANISO pictures that are included in
the summary.html file would immediately show you whether it is the case that
a strong diffraction pattern was truncated by the detector edges. 


 With best wishes,

  Gerard

[1] https://www.globalphasing.com/autoproc/

--
On Tue, Feb 22, 2022 at 11:56:50AM -0800, Bernhard Rupp wrote:
> Hmm…compliment, pretty darn good density map for 1.7 A….maybe look at the 
> resolution cut-off. 
> 
> If it is at a significant level, it could be truncation ripples?
> 
> Otherwise I second the noise opinion if it is already a well completed model.
> 
>  
> 
> Cheers, BR
> 
>  
> 
>  
> 
> From: CCP4 bulletin board  On Behalf Of S
> Sent: Monday, February 21, 2022 21:34
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] Negative density
> 
>  
> 
> Hi All,
> 
>  
> 
> I am getting this negative density in the centre of the ring. Could you 
> please help me with this?
> 
>  
> 
>  
> 
> Resolution: 1.7A
> 
> 2FoFc - 1.5
> 
> FoFc - 3.0
> 
>  
> 
> Thanks in advance.
> 
> Regards,
> 
> Renu
> 
>  
> 
>   _  
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB 
>  =1 
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Help with interpreting Tyrosine modification

[Gerard Bricogne]

Dear Misba,

 Thank you for your reply and for the very clear picture. I hope you
will be able to share the result once the mystery is solved.

 With best wishes,

  Gerard.

--
On Sat, Jan 29, 2022 at 03:32:30PM +0100, Misba Ahmad wrote:
> Dear Gerard,
> The data were collected at 0.966Å and I can see the anomalous peaks for As
> at Cysteines which are modified and I have correctly modelled those (see
> image below). However, at this Tyr, I don't see an anomalous signal.
> 
> [image: 4.png]
> 
> On Sat, Jan 29, 2022 at 3:06 PM Gerard Bricogne 
> wrote:
> 
> > Dear Misba,
> >
> >  A wild guess: have you considered the possibility that this extra
> > density could be a cacodylate adduct? Cacodylate is well known to react
> > with
> > thiols - see
> >
> >
> > https://febs.onlinelibrary.wiley.com/doi/pdfdirect/10.1016/0014-5793(72)80224-2
> >
> > Here the chemistry is different but you never know. If your data are
> > redundant enough that you have good anomalous completeness, and were
> > collected above the As K-edge (11.8667 keV), it might be a good idea to
> > compute an anomalous difference Fourier and check for the presence of a
> > peak
> > at the same location as the highest one in your ordinary difference map.
> >
> >  Only a wild guess, though ... .
> >
> >
> >  With best wishes,
> >
> >   Gerard.
> >
> > --
> > On Sat, Jan 29, 2022 at 12:18:58PM +0100, Misba Ahmad wrote:
> > > Placing a water molecule satisfies most of the density and forms nice
> > > H-bonds but there is still some residual density left (8.6 and 5.6 rmsd).
> > >
> > > Best
> > > Misbha
> > > [image: 3.png]
> > >
> > >
> > > On Sat, Jan 29, 2022 at 11:05 AM Klaus Futterer 
> > > wrote:
> > >
> > > > Looks more like water molecules. Phosphorylation would give a much
> > bigger
> > > > peak, and shape of density does not fit either. I don't think this is a
> > > > covalent modification. Model some water molecules and see what the
> > > > distances are and what difference density is left.
> > > >
> > > >
> > > > Klaus
> > > >
> > > >
> > > > ===
> > > > Klaus Fütterer, PhD
> > > > Reader in Structural Biology
> > > >
> > > >
> > > > School of Biosciences
> > > > LES CollegeEmail:
> > > > k.futte...@bham.ac.uk
> > > > University of Birmingham Phone: +44 - 121 - 414
> > > > 5895
> > > > Birmingham, B15 2TT, UK(voice mail messages
> > > > will forward to my email inbox)
> > > >
> > > > My normal working hours are Mon - Fri 8.30 - 5.30 pm.
> > > >
> > > >
> > > > ===
> > > > --
> > > > *From:* CCP4 bulletin board  on behalf of
> > > > misba.ah...@gmail.com 
> > > > *Sent:* 29 January 2022 09:45:24
> > > > *To:* CCP4BB@JISCMAIL.AC.UK
> > > > *Subject:* Re: [ccp4bb] Help with interpreting Tyrosine modification
> > > >
> > > > Hi Tom,
> > > > The protein was expressed in E Coli.
> > > >
> > > > Best
> > > > Misbha
> > > >
> > > > On Sat, 29 Jan 2022, 10:18 Peat, Tom (Manufacturing, Clayton) <
> > > > tom.p...@csiro.au> wrote:
> > > >
> > > >> Hello Misba,
> > > >>
> > > >> Doesn't quite look like a phosphate, maybe O-sulfation?
> > > >> Maybe just as important as the buffer and crystallisation conditions
> > > >> would be how it was expressed? Insect cells?
> > > >>
> > > >> Best of luck, tom
> > > >>
> > > >> Tom Peat, PhD
> > > >>
> > > >> Biomedical Program, CSIRO
> > > >> tom.p...@csiro.au
> > > >>
> > > >> --
> > > >> *From:* CCP4 bulletin board  on behalf of
> > Misba
> > > >> Ahmad 
> > > >> *Sent:* Saturday, January 29, 2022 8:12 PM
> > > >> *To:* CCP4BB@JISCMAIL.AC.UK 
> > > >> *Subject:* [ccp4bb] Help with interpreting Tyrosine modification
> > > >>
> > &g

Re: [ccp4bb] Help with interpreting Tyrosine modification

[Gerard Bricogne]

Dear Misba,

 A wild guess: have you considered the possibility that this extra
density could be a cacodylate adduct? Cacodylate is well known to react with
thiols - see 

https://febs.onlinelibrary.wiley.com/doi/pdfdirect/10.1016/0014-5793(72)80224-2

Here the chemistry is different but you never know. If your data are
redundant enough that you have good anomalous completeness, and were
collected above the As K-edge (11.8667 keV), it might be a good idea to
compute an anomalous difference Fourier and check for the presence of a peak
at the same location as the highest one in your ordinary difference map.

 Only a wild guess, though ... .


 With best wishes,

  Gerard.

--
On Sat, Jan 29, 2022 at 12:18:58PM +0100, Misba Ahmad wrote:
> Placing a water molecule satisfies most of the density and forms nice
> H-bonds but there is still some residual density left (8.6 and 5.6 rmsd).
> 
> Best
> Misbha
> [image: 3.png]
> 
> 
> On Sat, Jan 29, 2022 at 11:05 AM Klaus Futterer 
> wrote:
> 
> > Looks more like water molecules. Phosphorylation would give a much bigger
> > peak, and shape of density does not fit either. I don't think this is a
> > covalent modification. Model some water molecules and see what the
> > distances are and what difference density is left.
> >
> >
> > Klaus
> >
> >
> > ===
> > Klaus Fütterer, PhD
> > Reader in Structural Biology
> >
> >
> > School of Biosciences
> > LES CollegeEmail:
> > k.futte...@bham.ac.uk
> > University of Birmingham Phone: +44 - 121 - 414
> > 5895
> > Birmingham, B15 2TT, UK(voice mail messages
> > will forward to my email inbox)
> >
> > My normal working hours are Mon - Fri 8.30 - 5.30 pm.
> >
> >
> > ===
> > --
> > *From:* CCP4 bulletin board  on behalf of
> > misba.ah...@gmail.com 
> > *Sent:* 29 January 2022 09:45:24
> > *To:* CCP4BB@JISCMAIL.AC.UK
> > *Subject:* Re: [ccp4bb] Help with interpreting Tyrosine modification
> >
> > Hi Tom,
> > The protein was expressed in E Coli.
> >
> > Best
> > Misbha
> >
> > On Sat, 29 Jan 2022, 10:18 Peat, Tom (Manufacturing, Clayton) <
> > tom.p...@csiro.au> wrote:
> >
> >> Hello Misba,
> >>
> >> Doesn't quite look like a phosphate, maybe O-sulfation?
> >> Maybe just as important as the buffer and crystallisation conditions
> >> would be how it was expressed? Insect cells?
> >>
> >> Best of luck, tom
> >>
> >> Tom Peat, PhD
> >>
> >> Biomedical Program, CSIRO
> >> tom.p...@csiro.au
> >>
> >> --
> >> *From:* CCP4 bulletin board  on behalf of Misba
> >> Ahmad 
> >> *Sent:* Saturday, January 29, 2022 8:12 PM
> >> *To:* CCP4BB@JISCMAIL.AC.UK 
> >> *Subject:* [ccp4bb] Help with interpreting Tyrosine modification
> >>
> >> Hi all,
> >> I am trying to interpret this strong difference density peak (11.33 rmsd)
> >> that shows up on the tyrosine residue. Any help would be greatly
> >> appreciated.
> >>
> >> Purification buffer: 20mM HEPES pH 7.5, 250mM NaCl, 1mM TCEP, 5mM DTT
> >> Crystallisation condition: Sodium propionate, Sodium cacodylate, BIS-TRIS
> >> propane, PEG 1500
> >>
> >> Best
> >> Misbha
> >> [image: Picture1.png]
> >> [image: Picture2.png]
> >>
> >> --
> >>
> >> To unsubscribe from the CCP4BB list, click the following link:
> >> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> >>
> >
> > --
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> >
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Make Ligand error

[Gerard Bricogne]

Dear Eleanor and Ron,

I remember seeing this derivative used to great effect by Alan Wonacott for
solving the structure of GAPDH from B. Stearothermophilus in 1973-75. The
data were collected on film by Jean-Claude Thierry on the first prototype of
the Arndt-Wonacott rotation camera and the processing was done by very
primitive software. As a PhD student (of David Blow) I had a chance to have
a hand in that phasing, first tweaking some parts of the PHARE program for
heavy-atom refinement and phasing, then grafting into it the calculation of
Hendrickson-Lattman coefficients for use in my phase combination program to
exploit the 222 NCS of these crystals.

Once I got the iterative NCS averaging plus phase combination to converge, I
remember putting those phases back into PHARE and re-refining the heavy-atom
parameters. Even with such rudimentary data collection hardware, there were
extremely clear (5-sigma, I think) peaks on the iodines in the anomalous
difference Fourier map in each copy of the protein. They were distributed at
the vertices of an equilateral triangle, with the Hg atom in the middle.

It gives a spectacular derivative when it binds. This was SIRAS phasing, but
it would be a real delight to do MAD phasing with, although probably quite
sensitive to radiation damage (however that can help the phasing too). 

With best wishes,

Gerard.

--
On Thu, Jan 27, 2022 at 06:35:08PM +, Ronald E. Stenkamp wrote:
> K2HgI4 worked for solving hemerythrin in 1975.  The various species of HgIx 
> in the solution found several binding sites.  Some were single Hg atoms 
> between cysteines and others were HgI bound elsewhere.  Ron Stenkamp
> 
> 
> From: CCP4 bulletin board  on behalf of Eleanor Dodson 
> <176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk>
> Sent: Thursday, January 27, 2022 6:25 AM
> To: CCP4BB@JISCMAIL.AC.UK 
> Subject: Re: [ccp4bb] Make Ligand error
> 
> YUVARAJI sent this email re HgI4 coordinates.
> The ligand problem has been solved and the map is beautiful, with very sharp 
> anomalous difference peaks showing I and HG.
> It reveals a lot of substitution - five clusters to 175 residues and a lot of 
> alternate conformations. We tried many years ago to us this (pre-SAD phasing) 
> and again got too much substitution, not too little. Have other people used 
> it successfully? I would be interested to know..
> Eleanopr
> 
> On Tue, 25 Jan 2022 at 13:41, Eleanor Dodson 
> mailto:eleanor.dod...@york.ac.uk>> wrote:
> Thank you
> I can look at it and maybe be useful..
> HgI3c was a heavy atom we tried to use many years back for insulin!
> 
> Eleanor
> 
> On Tue, 25 Jan 2022 at 12:45, YUVARAJ I 
> mailto:yuvee...@gmail.com>> wrote:
> 
> Respected Prof. Eleanor Dodson,
> 
> Thank you for your reply.
> 
> I have added Mercury(II) potassium iodide from (Heavy Atom screen Hg from 
> Hampton catlog no: HR2-446 )
> 
> https://hamptonresearch.com/uploads/support_materials/Heavy_Atom_UG.pdf
> 
> General observations about this Heavy atom: HgI3 can be formed from K2HgI4 
> with the addition of excess KI.
> 
>  Using Anomalous signal obtained from this data, I have built the model using 
> CRANK2.
> 
> I will share the data and the pdb file with you.
> 
> It would be a great help, If you could help me in fitting this ligand.
> 
> Many Thanks
> 
> Yuvaraj
> 
> On Tue, Jan 25, 2022 at 5:18 PM Eleanor Dodson 
> <176a9d5ebad7-dmarc-requ...@jiscmail.ac.uk>
>  wrote:
> Dear Yuvara,
>   I have just read this..
> Your first problem was that you had added the molecule at 3 symmetry related 
> positions, and once you corrected that the R factor dropped..
> The negative density at the centre of your complex is odd.
> Are you sure of its chemical composition?
> And have you checked the peaks in the anomalous map.
> I can explain how to do that, or if you are allowed to send the data I can 
> show you what to expect.
> 
> Eleanor Dodson
> 
> 
> On Tue, 25 Jan 2022 at 04:41, Paul Emsley 
> mailto:pems...@mrc-lmb.cam.ac.uk>> wrote:
> 
> 
> On 25/01/2022 04:10, YUVARAJ I wrote:
> Respected Prof. Paul
> I added this ligand at three places, That why log file showed three molecules,
> I got multiple densities of the same ligand.  For testing, I  added it at 
> only one place and refined it.
> It doesn't help, I am getting the same output.
> Kindly let me know How I could fix this ligand.
> Thank you
> 
> Regards
> Yuvara
> 
> On Tue, Jan 25, 2022 at 12:03 AM Paul Emsley 
> mailto:pems...@mrc-lmb.cam.ac.uk>> wrote:
> 
> 
> On 24/01/2022 11:11, YUVARAJ I wrote:
> Respected Prof. Paul,
> Thank you for your kind reply, After refinement using refmac gives output,
> When I visualize in coot, the size of the molecule is small.
> but when I do real space refinement with coot, It attains the original size.
> I have attached the output and refmac log file with this mail. kindly let me 
> know how I could fix this.
> Many 

Re: [ccp4bb] Make Ligand error

[Gerard Bricogne]

Dear Yuvaraj,

 That is a lovely derivative, but the chemical species involved in that
derivatisation is not HgI4, nor the anion even (HgI4)2- , but is often the
anion (HgI3)- , with a nice symmetrical planar structure - see for instance

   https://pubchem.ncbi.nlm.nih.gov/compound/Triiodomercurate_1

The Molfile and SDF files at 

   https://www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI:51567

contain coordinates for the Mercury and Iodine atoms that should enable you
to create a dictionary for it. Or perhaps someone else can direct you to a
a ready-made refinement dictionary - I couldn't find one.


 With best wishes,

  Gerard.

--
On Sat, Jan 22, 2022 at 11:04:27PM +0530, YUVARAJ I wrote:
> Respected Professors,
> 
> I have solved a protein structure using anomalous signal using
> mercury(II)potassium Iodide(K2HgI4).
> 
> I wanted to submit the structure of the protein with mercury(II) potassium
> iodide to PDB.
> 
> I am facing problems while making the ligand (HGI4) . HGI4 is not available
> in the pdb.
> 
> Make Ligand in CCP4 is showing error
> 
> " The input ligands/molecules contains metal or other heavier atoms
> 
> Acedrg currently deals with ligands/molecules with following elements only
> 
> C, N, O, S, P, B, F, Cl, Br, I, H"
> 
> I tried to make cif file from other softwares, given as input in coot, It
> is also showing errors,  dictionary no restraints were found.
> 
> For generating cif dictionary, I used prodrg server
> 
> It is showing error
> 
> "PRODRG> Found unsupported atom HG in Molfile.
> 
>  ERRDRG> Currently only N, C, O, S, P, Cl, Br, F, I are supported. "
> 
> 
> If I fix each atom seperately such as Hg and Iodine separately, It is
> having clashes with other atoms during validation,
> 
> kindly let me know how I can fix this HGI4 ?
> 
> I have attached the screenshots for reference.
> 
> -- 
> 
> Regards
> Yuvaraj
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Strange cysteines

[Gerard Bricogne]

Could it not just be classical radiation damage, that is known to love
breaking SS bonds? If I understood correctly, single-particle cryo-EM
inflicts much higher radiation doses than X-ray crystallography.

Best wishes,

Gerard.

--
On Wed, Dec 22, 2021 at 09:51:59AM +, Weiergräber, Oliver H. wrote:
> Hmm, this may indeed be a disulfide bond, but the sulfur atoms do not seem to 
> occupy their density centroids.
> They could be either _pushed_ apart by the refinement algorithm (which one 
> are you using?) or _pulled_ apart due to incorrect geometry in their 
> neighbourhood.
> 
> Cheers
> Oliver
> 
> ==
>   PD Dr. Oliver H. Weiergräber
>   Institut für Biologische Informationsprozesse
>   IBI-7: Strukturbiochemie
>   Tel.: +49 2461 61-2028
>   Fax: +49 2461 61-9540
> ==
> 
> 
> 
> From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Hochberg, 
> Georg [georg.hochb...@mpi-marburg.mpg.de]
> Sent: 22 December 2021 10:06
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] Strange cysteines
> 
> Dear CCP4ers,
> 
> 
> We have recently solved the structure of an enzyme by cryoEM, which has two 
> cysteines at its dimer interface, one in each monomer. The density around 
> these two cysteines is very odd (see picture). They are too far apart for a 
> disulphide bond, and there is nothing around these two cysteines that could 
> help coordinate a metal. This density is also not a result of symmetry 
> constraints in the density refinement either.  We'd be very grateful for any 
> ideas.
> 
> [cid:b92417da-97f2-4dc3-9b5c-92278a5318fd]
> 
> 
> All the best and happy holidays,
> 
> Georg Hochberg
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> 
> 
> 
> 
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Astrid Lambrecht,
> Prof. Dr. Frauke Melchior
> 
> 
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Erica Saphire speaking at ALS Colloquium in 6 hours

[Gerard Bricogne]

Thank you James! And good afternoon California.

Gerard.

--
On Wed, Dec 08, 2021 at 12:00:09PM -0800, James Holton wrote:
> Good news!  Erica's talk will be recorded!  I will update on this thread
> when the link is up.
> 
> Goodnight Europe,
> 
> -James Holton
> MAD Scientist
> 
> 
> On 12/8/2021 11:16 AM, Gerlind Sulzenbacher wrote:
> > Dear James,
> > 
> > thank you so much for putting into place all these outstanding seminars.
> > 
> > Here a plead to access not only Erica Saphire's talk, but all the
> > previous talks.
> > 
> > I had a look at https://als.lbl.gov/news-events/seminars/, great list of
> > seminars, but no way to access any recording.
> > 
> > I know, this plead puts just extra work on you.
> > 
> > In case you recorded or you will record, many thanks for sharing, in the
> > limits of legal boundaries.
> > 
> > Otherwise, just forget and thanks again for always being there to push
> > forward great science.
> > 
> > With best wishes,
> > Gerlind
> > 
> > 
> > 
> > 
> > 
> > On 08/12/2021 18:38, Gerard Bricogne wrote:
> > > Dear James,
> > > 
> > >   Thank you for this notification about what should be a
> > > captivating and
> > > inspiring talk.
> > > 
> > >   The time of 3pm PST is a little bit on the rough side for most
> > > European
> > > would-be listeners: is there a chance of putting in a plea that this
> > > talk be
> > > recorded and made available on demand, for at least a short period
> > > of time,
> > > through a link that you would broadcast soon after the event?
> > > 
> > >   Thank you in advance!
> > > 
> > > 
> > >   With best wishes,
> > > 
> > >    Gerard.
> > > 
> > > -- 
> > > On Wed, Dec 08, 2021 at 09:06:53AM -0800, James Holton wrote:
> > > > Greetings all!
> > > > 
> > > > At 3pm PST Dec 8, 2021 (California time),
> > > > 
> > > > I managed to get Erica Saphire to speak about her recent work at
> > > > the ALS
> > > > Colloquium.  It is a forum for users and staff of the Advanced
> > > > Light Source
> > > > to communicate with each other about how we use the light. I
> > > > asked Erica
> > > > because she is a long-time, highly productive user who is doing
> > > > some very
> > > > timely work. Her title:
> > > > 
> > > > A Global Consortium, Next-Generation SARS-CoV-2 Antibody
> > > > Therapeutics and
> > > > Stabilized Spike
> > > > 
> > > > I think it absolutely brilliant how she's gotten so many
> > > > different entities
> > > > to work together.
> > > > 
> > > > Thought that might be of interest if you have the time!
> > > > 
> > > > Free and open to all, and I'm not sure if this is being recorded
> > > > or not.
> > > > Here are the links:
> > > > 
> > > > https://lbnl.zoom.us/j/97680529569
> > > > https://als.lbl.gov/news-events/seminars/
> > > > 
> > > > -James Holton
> > > > MAD Scientist
> > > > 
> > > > 
> > > > 
> > > > 
> > > > To unsubscribe from the CCP4BB list, click the following link:
> > > > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> > > > 
> > > > This message was issued to members of www.jiscmail.ac.uk/CCP4BB,
> > > > a mailing list hosted by www.jiscmail.ac.uk, terms & conditions
> > > > are available at https://www.jiscmail.ac.uk/policyandsecurity/
> > > 
> > > 
> > > To unsubscribe from the CCP4BB list, click the following link:
> > > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> > > 
> > > This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> > > mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
> > > available at https://www.jiscmail.ac.uk/policyandsecurity/
> > 
> > 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Erica Saphire speaking at ALS Colloquium in 6 hours

[Gerard Bricogne]

Dear James,

 Thank you for this notification about what should be a captivating and
inspiring talk.

 The time of 3pm PST is a little bit on the rough side for most European
would-be listeners: is there a chance of putting in a plea that this talk be
recorded and made available on demand, for at least a short period of time,
through a link that you would broadcast soon after the event?

 Thank you in advance!


 With best wishes,

  Gerard.

--
On Wed, Dec 08, 2021 at 09:06:53AM -0800, James Holton wrote:
> Greetings all!
> 
> At 3pm PST Dec 8, 2021 (California time),
> 
> I managed to get Erica Saphire to speak about her recent work at the ALS
> Colloquium.  It is a forum for users and staff of the Advanced Light Source
> to communicate with each other about how we use the light. I asked Erica
> because she is a long-time, highly productive user who is doing some very
> timely work. Her title:
> 
> A Global Consortium, Next-Generation SARS-CoV-2 Antibody Therapeutics and
> Stabilized Spike
> 
> I think it absolutely brilliant how she's gotten so many different entities
> to work together.
> 
> Thought that might be of interest if you have the time!
> 
> Free and open to all, and I'm not sure if this is being recorded or not. 
> Here are the links:
> 
> https://lbnl.zoom.us/j/97680529569
> https://als.lbl.gov/news-events/seminars/
> 
> -James Holton
> MAD Scientist
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] chain on 2-fold axis?

[Gerard Bricogne]

Dear Peer,

 Have you looked at your images to check whether there is streakiness in
some parts of the diffraction pattern? You could have a case of lattice
translocation disorder, a nuisance often associated with tNCS but for which
there are remedial methods available.


 With best wishes,

  Gerard.


On Thu, Aug 26, 2021 at 11:54:06AM +0200, Peer Mittl wrote:
> Der CCP4 community,
> 
> Is there a refinement program that can handle protein monomers sitting on
> crystallographic 2-folds?
> 
> This is probably a strange question but we have the following situation. We
> have a 2.6 Ang datasets in SG P3221 (Rpim=4%, Isa=19.6) and a clear molrep
> solution with 2 chains, albeit with tNCS (0/0/0.5) that can be refined to
> around 27/33% Rfactor. According to Vm a third chain could be present. So
> far so good, but there is clear difference ED for a third chain sitting
> exactly on the 2-fold. Since the protein has a peculiar shape, one can tell
> even its orientation. I can relax the symmetry to P32 (or even P1) and place
> the missing chain with 50% occupancy on the 2-fold. This model can be
> refined, but I do not like this work around, because the data is clearly
> P3221.
> 
> Any hints on similar crystal pathologies and how they have been handled
> would be helpful.
> 
> All the best,
> Peer
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/

--
 =======
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===



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

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

[ccp4bb] Standardised presentation of archived X-ray diffraction data quality metrics for PDB entries, consistent with the PDBx/mmCIF dictionary

[Gerard Bricogne]

Dear all,

 It is probably an all-too-frequent observation that

 (1) the *transfer* of X-ray data quality metrics (DQMs for short) from
 Table 1 in an MX structure paper to the PDB archive can be a lossy
 process, and 

 (2) the *presentation* of those DQMs that are actually archived can be
 surprisingly different across the various wwPDB front-ends to the
 PDB provided by the RCSB, PDBe and PDBj .

 We are pleased to offer a Web tool at 

   https://staraniso.globalphasing.org/table1/

that retrieves all available DQMs from the archived mmCIF file associated
with a PDB entry and presents them in a standardised tabular form. The
corresponding documents have been pre-generated for all relevant PDB entries
and are updated automatically on a weekly basis - either if the PDB entry
itself (model mmCIF) or the published PDBx/mmCIF dictionary [1] has changed.

 The simplest mode of use is to enter the PDB identifier of interest
into the box at the top of the landing page, then click on the Go button. A
facility to access the PDB according to any of 14 other attributes is also
provided. The top of the form for each given PDB entry contains hyperlinks
to the RCSB, PDBe and PDBj presentations of its DQMs, so as to facilitate
comparisons.

 Strict and explicit consistency with the PDBx/mmCIF dictionary [1,2]
has been a major goal in this work: throughout each Table, hovering over an
item in the left-hand side column will show its exact name in the PDBx/mmCIF
dictionary, while hovering over an item value in the right-hand side column
will show the associated item definition in that same dictionary.


 We hope that this tool will prove useful, and will welcome enquiries
and any feedback on it that would enable us to improve it.


 With best wishes,

Clemens and the GPhL developers

[1] https://mmcif.wwpdb.org/dictionaries/ascii/mmcif_pdbx_v50.dic
[2] https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Index/



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

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

Re: [ccp4bb] new section in IUCrData

[Gerard Bricogne]

Dear Loes,

This is very welcome news !!

With best wishes,

Gerard.

--
On Wed, Aug 04, 2021 at 10:34:38AM +, Kroon-Batenburg, L.M.J. (Loes) wrote:
> Dear all,
> 
> 
> I would like to attract you attention to the following.
> 
> 
> Best wishes,
> 
> Loes Kroon-Batenburg
> 
> ---
> 
> IUCrData to publish "Raw" Data Letters
> 
> 
> IUCrData, the peer-reviewed open-access data publication from the 
> International Union of Crystallography (IUCr), is launching a new section for 
> authors to describe their unprocessed or "raw" diffraction images. This is a 
> collaborative innovation of IUCr Journals with the IUCr Committee on Data. 
> The new section will publish short descriptions of crystallographic raw data 
> sets in the biological, chemical or materials science fields and provide a 
> persistent link to the location of the raw data. This will allow researchers 
> to attract attention to particular features of the data that could be of 
> interest to methods and software developers or may be relevant to the 
> structural interpretation. The IUCr will adhere to the FAIR principles for 
> which the correctness and completeness of the metadata are crucial, and these 
> will be central to the reviewing process. The new section will be accepting 
> submissions from the autumn and anyone wanting to know more should contact 
> the IUCr Editorial Office (m...@iucr.org).
> 
> 
> 
> 
> ___
> 
> Dr. Loes Kroon-Batenburg
> 
> Dept. of Crystal and Structural Chemistry
> Bijvoet Center for Biomolecular Research
> Utrecht University
> Padualaan 8, 3584 CH Utrecht
> The Netherlands
> 
> E-mail : l.m.j.kroon-batenb...@uu.nl
> phone  : +31-30-2532865
> fax: +31-30-2533940
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] AW: [ccp4bb] (R)MS

[Gerard Bricogne]

Dear Jonathan,

You are right of course, as e.g. the standard deviations are in the same
unit as the measurements (or averages) themselves. The dynamic ranges are
also more manageable.

I couldn't help wanting to find something to say as a diversion to yet
another day marked by a stiff dose of virtual meetings - all highly
productive and absolutely necessary, but somehow lacking in jokes ... .

Best wishes,

Gerard.

--
On Thu, May 27, 2021 at 05:34:18PM +, Hughes, Jonathan wrote:
> hi gerard,
> 
> yes, but that's like saying that the height of a human being is 1.8 m +/- 
> 0.04 m². and if (thanks to robert!*)
> 
> "B = 8π2  where u is the r.m.s. displacement of a scattering center, and 
> <...> denotes time averaging"
> 
> it would seem to me that we would be able to interpret things MUCH more 
> easily with u rather than anything derived from u².
> 
> best
> 
> jon
> 
> 
> 
> *nice presentation, by the way, not that i know what a complex number is, 
> unfortunately, although i did once see someone trying to explain it to his 
> girlfriend with the help of a graph drawn in the sand on a beach in sardinia.
> 
> 
> 
> -Ursprüngliche Nachricht-
> Von: Gerard Bricogne 
> Gesendet: Donnerstag, 27. Mai 2021 19:05
> An: Hughes, Jonathan 
> Cc: CCP4BB@jiscmail.ac.uk
> Betreff: Re: [ccp4bb] AW: [ccp4bb] (R)MS
> 
> 
> 
> Dear Jonathan,
> 
> 
> 
> Isn't it six of one and sqrt(36) of the other ?
> 
> 
> 
> Best wishes,
> 
> 
> 
> Gerard.
> 
> 
> 
> --
> 
> On Thu, May 27, 2021 at 04:52:39PM +, Hughes, Jonathan wrote:
> 
> > hey!
> 
> > thank y'all for the informative (and swift!) answers! but, if the B factor 
> > (as defined) appears in a mathematical formulation, that doesn't make it an 
> > "appropriate" parameter for mobility/uncertainty. wouldn't √B be better, in 
> > the same way that, for humans, standard deviation (RMSD) is a more 
> > appropriate parameter of variability than variance? or am i missing 
> > something?
> 
> > cheers
> 
> > j
> 
> >
> 
> > Von: Ian Tickle mailto:ianj...@gmail.com>>
> 
> > Gesendet: Donnerstag, 27. Mai 2021 18:32
> 
> > An: Hughes, Jonathan 
> > mailto:jon.hug...@bot3.bio.uni-giessen.de>>
> 
> > Cc: CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK>
> 
> > Betreff: Re: [ccp4bb] (R)MS
> 
> >
> 
> >
> 
> > Hi Jonathan
> 
> >
> 
> > It's historical, it's simply how it appears in the expression for the 
> > Debye-Waller factor, i.e. exp(-B sin^2(theta)/lambda^2).  So it must have 
> > the same units as lambda^2.
> 
> >
> 
> > Cheers
> 
> >
> 
> > -- Ian
> 
> >
> 
> >
> 
> > On Thu, 27 May 2021 at 13:25, Hughes, Jonathan 
> > mailto:jon.hug...@bot3.bio.uni-giessen.de<mailto:jon.hug...@bot3.bio.uni-giessen.de%3cmailto:jon.hug...@bot3.bio.uni-giessen.de>>>
> >  wrote:
> 
> > o yes! but maybe the crystal people could explain to me why the B factor is 
> > the variance (with units of Ų) rather than the standard deviation (i.e. 
> > RMS, with units of Å) when, to my simple mind, the latter would seem be the 
> > more appropriate description of variability in space?
> 
> > cheers
> 
> > jon
> 
> >
> 
> > Von: CCP4 bulletin board
> 
> > mailto:CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK%3cmailto:CCP4BB@JISCMAIL.AC.UK>>>
> >  Im Auftrag von
> 
> > Pearce, N.M. (Nick)
> 
> > Gesendet: Donnerstag, 27. Mai 2021 12:38
> 
> > An: 
> > CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK%3cmailto:CCP4BB@JISCMAIL.AC.UK>>
> 
> > Betreff: Re: [ccp4bb] Analysis of NMR ensembles
> 
> >
> 
> > If you want something comparable to B-factors don’t forget to put the MSF 
> > in the B-factor column, not the RMSF. Will change the scaling of the tube 
> > radius considerably!
> 
> >
> 
> > Nick
> 
> >
> 
> > On 27 May 2021, at 11:16, Harry Powell - CCP4BB 
> > <193323b1e616-dmarc-requ...@jiscmail.ac.uk<mailto:193323b1e616-dmarc-requ...@jiscmail.ac.uk<mailto:193323b1e616-dmarc-requ...@jiscmail.ac.uk%3cmailto:193323b1e616-dmarc-requ...@jiscmail.ac.uk>>>
> >  wrote:
> 
> >
> 
> > Cool…
> 
> >
> 
> > Purely for visualisation this does look like the approved CCP4 way -
> 
> >
> 
> > 
> 
> >
> 
> > Harry
> 
> >
> 
> > On 27 May 2021, at 10:01, Stuart McNicholas 
&g

Re: [ccp4bb] AW: [ccp4bb] (R)MS

[Gerard Bricogne]

Dear Jonathan,

Isn't it six of one and sqrt(36) of the other ?

Best wishes,

Gerard.

--
On Thu, May 27, 2021 at 04:52:39PM +, Hughes, Jonathan wrote:
> hey!
> thank y'all for the informative (and swift!) answers! but, if the B factor 
> (as defined) appears in a mathematical formulation, that doesn't make it an 
> "appropriate" parameter for mobility/uncertainty. wouldn't √B be better, in 
> the same way that, for humans, standard deviation (RMSD) is a more 
> appropriate parameter of variability than variance? or am i missing something?
> cheers
> j
> 
> Von: Ian Tickle 
> Gesendet: Donnerstag, 27. Mai 2021 18:32
> An: Hughes, Jonathan 
> Cc: CCP4BB@JISCMAIL.AC.UK
> Betreff: Re: [ccp4bb] (R)MS
> 
> 
> Hi Jonathan
> 
> It's historical, it's simply how it appears in the expression for the 
> Debye-Waller factor, i.e. exp(-B sin^2(theta)/lambda^2).  So it must have the 
> same units as lambda^2.
> 
> Cheers
> 
> -- Ian
> 
> 
> On Thu, 27 May 2021 at 13:25, Hughes, Jonathan 
> mailto:jon.hug...@bot3.bio.uni-giessen.de>>
>  wrote:
> o yes! but maybe the crystal people could explain to me why the B factor is 
> the variance (with units of Ų) rather than the standard deviation (i.e. RMS, 
> with units of Å) when, to my simple mind, the latter would seem be the more 
> appropriate description of variability in space?
> cheers
> jon
> 
> Von: CCP4 bulletin board 
> mailto:CCP4BB@JISCMAIL.AC.UK>> Im Auftrag von Pearce, 
> N.M. (Nick)
> Gesendet: Donnerstag, 27. Mai 2021 12:38
> An: CCP4BB@JISCMAIL.AC.UK
> Betreff: Re: [ccp4bb] Analysis of NMR ensembles
> 
> If you want something comparable to B-factors don’t forget to put the MSF in 
> the B-factor column, not the RMSF. Will change the scaling of the tube radius 
> considerably!
> 
> Nick
> 
> On 27 May 2021, at 11:16, Harry Powell - CCP4BB 
> <193323b1e616-dmarc-requ...@jiscmail.ac.uk>
>  wrote:
> 
> Cool…
> 
> Purely for visualisation this does look like the approved CCP4 way -
> 
> 
> 
> Harry
> 
> On 27 May 2021, at 10:01, Stuart McNicholas 
> <19a0c5f649e5-dmarc-requ...@jiscmail.ac.uk>
>  wrote:
> 
> Drawing style (right menu in display table) -> Worm scaled by -> Worm
> scaled by NMR variability
> 
> in ccp4mg?
> 
> This changes the size of the worm but not the colour.
> 
> On Thu, 27 May 2021 at 09:56, Harry Powell - CCP4BB
> <193323b1e616-dmarc-requ...@jiscmail.ac.uk>
>  wrote:
> 
> Anyway, thanks to all those who answered my original question - especially
> 
>Tristan: Chimerax (+ his attached script)
>Michal, Scott: Theseus (https://theobald.brandeis.edu/theseus/)
>Bernhard: Molmol (https://pubmed.ncbi.nlm.nih.gov/8744573/ )
>Rasmus CYRANGE (http://www.bpc.uni-frankfurt.de/cyrange.html) and 
> https://www.ccpn.ac.uk/ (of course…)
>Andrew (uwmn - not sure if this is buildable on a modern box)
>Smita: PyMol (not sure if I’m allowed to say that on ccp4bb…)
> 
> or I could script it and use Gesamt or Superpose for the superposition if I 
> wanted to stay in the ccp4 universe and had the time to spare ;-)
> 
> Harry
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of 
> www.jiscmail.ac.uk/CCP4BB, a mailing list 
> hosted by www.jiscmail.ac.uk, terms & conditions 
> are available at https://www.jiscmail.ac.uk/policyandsecurity/
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of 
> www.jiscmail.ac.uk/CCP4BB, a mailing list 
> hosted by www.jiscmail.ac.uk, terms & conditions 
> are available at https://www.jiscmail.ac.uk/policyandsecurity/
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members 

Re: [ccp4bb] deposition of unmerged data

[Gerard Bricogne]

Dear Marcin,

 Thank you for this announcement of a nifty piece of work.

 Perhaps not every reader of the CCP4BB would know what the "GPhL"
acronym refers to, so we thought we would clarify this and say explicitly
that it stands for "Global Phasing Limited" and point the interested users
to the following Wiki page for information about these deposition files:

https://www.globalphasing.com/buster/wiki/index.cgi?DepositionMmCif


 With best wishes,

   The BUSTER developers

--
On Thu, Apr 29, 2021 at 05:32:00PM +0200, Marcin Wojdyr wrote:
> Dear All,
> 
> as was announced by the PDB a month ago, it's now possible to include scaled
> unmerged data in a deposition to the PDB (before that it was possible
> only in a limited way).
> 
> You can do it by simply adding unmerged data (from MTZ or XDS_ASCII
> file) to the data file that you'd normally deposit (mmCIF or MTZ), in
> this web app:
> 
> https://project-gemmi.github.io/wasm/mxdepo.html
> 
> If you use GPhL software - it already has tools that prepare mmCIF
> files with unmerged data, use them instead of this web app.
> 
> Having unmerged data will help method developers, so even if you
> already uploaded the experimental data file, but your deposition is
> not locked yet (or if it can be unlocked), and if you can find scaled
> unmerged data, please add it!
> 
> In case of any problems with the web page - let me know.
> 
> Regards,
> Marcin
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Can twinning be seen in the diffraction pattern?

[Gerard Bricogne]

cyandsecurity/
> > 
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/

-- 

 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===



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

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

Re: [ccp4bb] Student Question--Negative Difference Density in some Histidine side chains in Iron Coordination complex in 2XGF T4 Phage Model Structure

[Gerard Bricogne]

Dear Patrick, Mark and colleagues,

 Examining the data associated to PDB entry 2XGF using the PDBpeep
server, i.e. at 

  http://staraniso.globalphasing.org/cgi-bin/PDBpeep.cgi?ID=2xgf

shows a large region (marked up in dark blue) of missing measurements where
the analysis of the trends in the distribution of the local average I/sig(I)
would have led to expect statistically significant intensities. Such
systematic patterns of missing data are never good news when it comes to
maps.

 This raises a couple of questions for you, Mark:

 1. this is not the shape of a standard cusp, so would there have been
features of the crystal morphology that made some regions of reciprocal
space hard to reach in an experiment, apart from the usual cusp caused by
the 2-fold axis being too close to the rotation axis? 

 2. this pattern of missing data makes it rather surprising that the 
completeness reported in the paper is about 99%, all the way out to the
outer resolution limit; the STARANISO logfile, accessible at  

  http://staraniso.globalphasing.org/PDB/2xgf.log

shows significantly lower values, even for the ellipsoidal completeness, of
about 0.7 at the highest resolution, for the deposited data.

 Did you perhaps deposit only part of the data you collected for the
remote wavelength? For example, only one of several orientations that you
might have collected in order to try and fill the cusp? 

 This may seem a digression from the original question about negative
difference density, but clearly any systematically missing data can create
additional artefacts in maps and difference maps, besides those originating
from chemical or radiation damage related causes.


 With best wishes,

 Claus and Gerard.

--
On Mon, Feb 22, 2021 at 07:51:11PM +0100, Mark J van Raaij wrote:
> Hi Patrick,
> couldn't see any text in you email, just the subject and the picture, but 
> 2XGF is our T4 long tail fibre tail tip structure from 2010. 
> (2XGF stands for "2nd eXtraordinary Great Fibre", at least that's what I 
> *modestly* imagine..).
> I think it's probably one or more of: 
> - noise (was this contoured at 3sigma? or at a specific e/Å3 level? at the 
> end of refinements 3sigma corresponds to less e/Å3 than at the start, or at 
> least it should).
> - perhaps a small percentage of another metal than iron in the site (Co, Ni, 
> Cu, Zn?), it's quite clear most of it was iron though from the X-ray 
> fluorescence spectrum and the fact that the MAD phasing worked
> - perhaps some radiation damage
> - ripple effects around the heavy atom sites
> Resolution was 2.2Å and data was 99.9% complete, multiplicity 3.8, more 
> statistics here: https://www.pnas.org/content/107/47/20287/tab-figures-data 
>  (paper 
> https://www.pnas.org/content/107/47/20287). 
> We didn't consider lowering the occupancy of the irons, or changing from Fe2+ 
> to Fe3+, because that would have meant less electrons, not more as suggested 
> by the positive density.
> In any case, happy that this thread serves to learn something more from the 
> comments by the experts.
> Mark
> 
> Mark J van Raaij
> Dpto de Estructura de Macromoleculas
> Centro Nacional de Biotecnologia - CSIC
> calle Darwin 3
> E-28049 Madrid, Spain
> Section Editor Acta Crystallographica F
> https://journals.iucr.org/f/
> 
> 
> > On 22 Feb 2021, at 16:16, Patrick Needham  wrote:
> > 
> > 
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1 
> >  > Shot 2021-02-22 at 10.08.36 AM.png>
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] autoPROC question

[Gerard Bricogne]

Dear Almudena,

 Let me give you a bit more guidance regarding the files of interest.

 The main user-oriented output from autoPROC is the "summary.html" file.
Numerous files are linked from within that html file, that are not meant to
be looked at individually with bare hands. This summary documents the steps
followed by autoPROC, and the final section "Finalising output" has all the
information you need as to what files contain what, with links to them so
that you can easily download them without having to inspect directories
yourself.

 It is the final sub-section, annotated "anisotropic", that contains
these links, as well as a printed Table 1. The file you want is called
"staraniso_alldata-unique.mtz". If you just used the XDS_ACII.HKL you would
forfeit the extra treatment by STARANISO. There is a "table1" link to the
contents, as a separate text file, of the box shaded in light green in the
summary file, and a link "xml" with this information in XML form for
harvesting by synchrotron auto-processing pipelines. You will also find a
link "Data_1_autoPROC_STARANISO_all.cif" that directs you to an mmCIF file
containing the final data, ready for deposition into the PDB. Finally, for
good measure, there is link to a full PDF report of the autoPROC results,
called "report_staraniso.pdf".

 I hope this guidance is of some help. The main message is: look at the
summary.html file.

 It has been clear for some time that users expect to be able to use
programs without having to look at the documentation, but it is a relatively
new development that they expect to be able to use the results without
having to look at any output :-) .


 With best wishes,

  Gerard.

--
On Sat, Nov 07, 2020 at 10:06:58PM +, Gerard Bricogne wrote:
> Dear Almudena,
> 
>  I am glad that you got some helpful responses by writing to the ccp4bb
> about your problem, and would like to thank those who sent them.
> 
>  Please note, however, that there is a user support mailing list for
> autoPROC, called "proc-deve...@globalphasing.com", where such questions will
> always be welcome and will be answered by the developers themselves.
> 
> 
>  With best wishes,
> 
>   Gerard.
> 
> --
> On Sat, Nov 07, 2020 at 08:45:39PM +0100, Almudena Ponce Salvatierra wrote:
> > Hi Kay, Michal, Guillermo,
> > 
> > thank you all for your answers.
> > 
> > @Kay Diederichs  and Michal, indeed I tried
> > with the XDS outputs first, since this is what I'm most familiar with.
> > However, when I load them in Xtriage to see how the data is going to look
> > overall, I see that only I, SIGI are there. See the screenshot attached.
> > 
> > @Guillermo Montoya  I am trying! :) My images
> > are from a Pilatus detector, in cbf format. Is what you sent in this later
> > email equivalent to "process -I Directory_1_002 -I Directory_1_003 -I
> > Directory_1_004 -I Directory_1_005 -I Directory_1_006 -I Directory_1_007 -I
> > Directory_1_008 -I Directory_1_009 -d 0comb -ANO"
> > 
> > You wrote -*Id* directory/image...cbf but I was not able to run it like
> > that... so I used -I... it's running now.
> > 
> > Thank you very much everyone. Have a nice Saturday evening!
> > 
> > Best,
> > 
> > Almu
> > 
> > El sáb., 7 nov. 2020 a las 20:09, Kay Diederichs (<
> > kay.diederi...@uni-konstanz.de>) escribió:
> > 
> > > Hello Almudena,
> > >
> > > XDS_ASCII.HKL _has_ all the information. Whether the HKL values of a given
> > > record of that file refer to I(+) or I(-) is worked out by the scaling
> > > program.
> > >
> > > HTH,
> > > Kay
> > >
> > > On Sat, 7 Nov 2020 19:07:59 +0100, Almudena Ponce Salvatierra <
> > > maps.fa...@gmail.com> wrote:
> > >
> > > >Hello everyone,
> > > >
> > > >I am using autoPROC in a series of datasets I referred to in an email a
> > > few
> > > >days ago.
> > > >
> > > >I would like to merge them and see if the resulting dataset has enough
> > > >anomalous signal as to phase.
> > > >
> > > >The thing is that, out of the massive output from autoPROC, I fail to 
> > > >find
> > > >which files to merge. I am using the command "combine_files -f ... -f ...
> > > >-o combined.mtz". But neither aimless_unmerged.mtz or XDS_ASCII.HKL 
> > > >files,
> > > >seem to contain any record of I(+)I(-) etc...
> > > >
> > > >I'll be very thankful for any suggestions.
> &

Re: [ccp4bb] autoPROC question

[Gerard Bricogne]

Dear Almudena,

 I am glad that you got some helpful responses by writing to the ccp4bb
about your problem, and would like to thank those who sent them.

 Please note, however, that there is a user support mailing list for
autoPROC, called "proc-deve...@globalphasing.com", where such questions will
always be welcome and will be answered by the developers themselves.


 With best wishes,

  Gerard.

--
On Sat, Nov 07, 2020 at 08:45:39PM +0100, Almudena Ponce Salvatierra wrote:
> Hi Kay, Michal, Guillermo,
> 
> thank you all for your answers.
> 
> @Kay Diederichs  and Michal, indeed I tried
> with the XDS outputs first, since this is what I'm most familiar with.
> However, when I load them in Xtriage to see how the data is going to look
> overall, I see that only I, SIGI are there. See the screenshot attached.
> 
> @Guillermo Montoya  I am trying! :) My images
> are from a Pilatus detector, in cbf format. Is what you sent in this later
> email equivalent to "process -I Directory_1_002 -I Directory_1_003 -I
> Directory_1_004 -I Directory_1_005 -I Directory_1_006 -I Directory_1_007 -I
> Directory_1_008 -I Directory_1_009 -d 0comb -ANO"
> 
> You wrote -*Id* directory/image...cbf but I was not able to run it like
> that... so I used -I... it's running now.
> 
> Thank you very much everyone. Have a nice Saturday evening!
> 
> Best,
> 
> Almu
> 
> El sáb., 7 nov. 2020 a las 20:09, Kay Diederichs (<
> kay.diederi...@uni-konstanz.de>) escribió:
> 
> > Hello Almudena,
> >
> > XDS_ASCII.HKL _has_ all the information. Whether the HKL values of a given
> > record of that file refer to I(+) or I(-) is worked out by the scaling
> > program.
> >
> > HTH,
> > Kay
> >
> > On Sat, 7 Nov 2020 19:07:59 +0100, Almudena Ponce Salvatierra <
> > maps.fa...@gmail.com> wrote:
> >
> > >Hello everyone,
> > >
> > >I am using autoPROC in a series of datasets I referred to in an email a
> > few
> > >days ago.
> > >
> > >I would like to merge them and see if the resulting dataset has enough
> > >anomalous signal as to phase.
> > >
> > >The thing is that, out of the massive output from autoPROC, I fail to find
> > >which files to merge. I am using the command "combine_files -f ... -f ...
> > >-o combined.mtz". But neither aimless_unmerged.mtz or XDS_ASCII.HKL files,
> > >seem to contain any record of I(+)I(-) etc...
> > >
> > >I'll be very thankful for any suggestions.
> > >
> > >Best,
> > >
> > >Almudena
> > >
> > >
> > >
> > >To unsubscribe from the CCP4BB list, click the following link:
> > >https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> > >
> > >This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> > mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
> > available at https://www.jiscmail.ac.uk/policyandsecurity/
> > >
> >
> > 
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> >
> > This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> > mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
> > available at https://www.jiscmail.ac.uk/policyandsecurity/
> >
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Quote source inquiry

[Gerard Bricogne]

Dear Harry,

 I think that sharp ice rings (or, better, a powder pattern from silicon
powder) are only part of the solution to the calibration of beam energy, as
there is an interaction with the detector distance. If I recall what I saw
in my now distant days at LURE, a precise energy calibration would be done
using an absorption edge. I can remember Richard Kahn using a Cu metal foil
to lock precisely onto an energy close to the Ytterbium edge he wanted to
use in a MAD experiment. When the beam energy is precisely established by
this diffraction-free method, then a Si powder allows a precise calibration
of detector distance (and location of beam centre). 


 With best wishes,

  Gerard.

--
On Thu, Jul 16, 2020 at 12:25:55PM +0100, Harry Powell - CCP4BB wrote:
> Hi
> 
> Does anyone bother collecting a powder image (e.g. Si powder) these days so 
> they actually have a reference that can be used to check both the wavelength 
> and the beam centre? Or is this considered just something that old folk do?
> 
> Harry
> 
> > On 16 Jul 2020, at 12:19, Gerard DVD Kleywegt  wrote:
> > 
> > There was a case a few years ago (not too many though) where a 1.6 Å 
> > structure had been solved using an incorrect value for the wavelength (~5% 
> > too low, leading to a cell that was slightly too small for its contents to 
> > be comfortable). It was later corrected so we could compare their 
> > validation statistics. Some interesting observations:
> > 
> > - the geometry had been very tightly restrained so that didn't give a clue
> >  about the cell error (WhatCheck only suggested a very small change)
> > 
> > - somewhat surprisingly (I thought) the Ramachandran plot did not improve in
> >  the correct model (0.3% outliers in the wwPDB validation report), and the
> >  sidechain rotamer outliers even got worse (from 1.5 to 2.5 %)
> > 
> > - the map looked surprisingly good for the incorrect cell
> > 
> > - however, RSR-Z told clearly that the map was not good enough for the 
> > claimed
> >  resolution - the model had 24% outliers! (3% in the corrected model which
> >  still only put it at the ~50th percentile)
> > 
> > - another good indicator was the clashscore (went from 44 to 7)
> > 
> > - the original model did not include an Rfree, but the R-value (>0.3 at 1.6Å
> >  resolution) ought to have provided a clue to the crystallographers and
> >  reviewers one would think
> > 
> > It would be interesting to see what would happen if the wavelength would be 
> > set 5% too high.
> > 
> > --Gerard
> > 
> > 
> > 
> > On Thu, 16 Jul 2020, Clemens Vonrhein wrote:
> > 
> >> Hi Robbie,
> >> 
> >> On Wed, Jul 15, 2020 at 07:23:15PM +, Robbie Joosten wrote:
> >>> 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.
> >> 
> >> Indeed.
> >> 
> >>> That said, the problem is uncommon now.
> >> 
> >> Not so sure about that: we all rely on an accurate value of the
> >> energy/wavelength from the instrument/beamline - and if that is off
> >> (for whatever reasons) it will result in incorrect cell dimensions and
> >> a systematic deviation from the various restraints.
> >> 
> >> This would even affect the best experiment done on the best crystal
> >> ... so fairly easy to spot at the refinement stage, especially if such
> >> an energy/wavelength offset is constant over a long period of time on
> >> a given instrument. To spot this at the data collection stage one
> >> would hope that at some point a crystal with very pronounced ice-rings
> >> will be looked at properly (and the fact these are not where we expect
> >> them to should cause some head-scratching).
> >> 
> >> Cheers
> >> 
> >> Clemens
> >> 
> >> 
> >> 
> >> To unsubscribe from the CCP4BB list, click the following link:
> >> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> >> 
> >> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> >> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> >> https://www.jiscmail.ac.uk/policyandsecurity/
> >> 
> > 
> > 
> > Best wishes,
> > 
> > --Gerard
> > 
> > **
> >   Gerard J. Kleywegt
> > 
> >  http://xray.bmc.uu.se/gerard   mailto:ger...@xray.bmc.uu.se
> > **
> >   The opinions in this message are fictional.  Any similarity
> >   to actual opinions, living or dead, is purely coincidental.
> > **
> >   Little known gastromathematical curiosity: let "z" be the
> >   radius and "a" the thickness of a pizza. Then the volume
> >of that pizza is equal 

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

[Gerard Bricogne]

Dear Herman and David,

 This thread seems inexhaustible :-) .

 On the matter of "measurement" vs. "observation", we seem again to be
in a situation described by the British idiom "half of one and half-a-dozen"
of the other, i.e. distinct but synonymous terms between which a choice is
quite indifferent.

 In the work on STARANISO and the documentation of that work, a
distinction had to be made between the two terms, for which readers are
referred to Ian's carefully crafted material at 

http://staraniso.globalphasing.org/anisotropy_about.html

and 

http://staraniso.globalphasing.org/staraniso_glossary.html

Here, a measurement is a number plucked out of examining the raw data,
namely an integrated intensity obtained by considering the pixel values
around the position in 3D reciprocal space predicted from an indexing
solution. The next step is to determine whether this qualifies as an
observation, in the sense of containing information that a structural model
would be expected to comply with. This determination is carried out by
computing a local average of I/sig(I) through reciprocal space and applying
a cut-off criterion based on a threshold value for that local average. Other
criteria can be considered, and are indeed offered by the program as
alternatives. Measurements complying with this selection criterion are then
called "observations". In this picture, an observation is defined as a
significant measurement. This basic distinction of vocabulary is then
extended to talking about "unmeasured" reflections (for which there weren't
any detector pixels to catch any photons at their predicted position - e.g.
in gaps between detector modules) and "unobserved" reflections (that are
unmeasured but for which the analysis of the I/sig(I) distribution predicts
that they would have been significant, had they been measured - e.g. in
cusps or missing angular ranges, as well as in module gaps etc.). The
display of the latter as blue dots in the STARANISO Reciprocal Lattice
Viewer then gives a vivid picture of the inadequacies of the experimental
protocol used, in failing to catch all the significant diffraction from the
sample.

 This being said, things could very well had been done the other way,
saying that the blindly integrated intensity was an observation, and that
the subsequent analysis was intended to determine whether you had really
measured something significant (i.e. a useful integrated intensity) by
making that observation. We were aware of this ambivalence, but felt that we
had to comply with the boundary condition that what we ended up with, after
conversion to an amplitude, had to be denoted "Fobs" ;-) . If the early
crystallographers had used the notation "Fmeas" for what they considered as
their experimental data, the choice of terminology would definitely have
gone the other way.

 As Graeme said, use the terminology you want, but document exactly what
you mean by it. The two URLs quoted above (especially the second) show that
this suggestion was conscientiously followed by the STARANISO developers.


 With best wishes,

  Gerard,

--
On Fri, Jul 03, 2020 at 10:22:43AM +, Schreuder, Herman /DE wrote:
> Dear David,
> 
> Thank you for your reaction. It has become clear to me that although most 
> people understand what I intended with “measurement”, in practice it is very 
> much in the eye of the beholder. It was suggested in the BB to use 
> observation instead, but I am fairly sure that some people will also have 
> issues with that.
> 
> The advantage of multiplicity/redundancy is that it does not mention what is 
> multiple or redundant and that one can refer to the program documentation for 
> an exact definition. Since most people are happy with the 
> multiplicity/redundancy they grew up with, that is the way it will stay.
> 
> Best regards,
> Herman
> 
> 
> 
> 
> Von: David Waterman 
> Gesendet: Freitag, 3. Juli 2020 10:49
> An: Schreuder, Herman /DE 
> Cc: CCP4BB@jiscmail.ac.uk
> Betreff: Re: [ccp4bb] AW: [ccp4bb] AW: [EXTERNAL] Re: [ccp4bb] number of 
> frames to get a full dataset?
> 
> 
> EXTERNAL : Real sender is dgwater...@gmail.com
> 
> Hi Herman,
> 
> I like the idea of MPR, but I continue to worry about the term "measurement". 
> The intensity associated with a particular reflection is a fit based on a 
> scaling model, and ultimately, depending on your integration software, may be 
> linked to a weighted sum of two raw measurements: the summation and 
> profile-fitted intensities. I think these are the measurements, not the 
> intensity derived during the scaling procedure. Sure, anyone who wants to be 
> even more pedantic than me will point out that these "raw measurements" are 
> also the result of fitting procedures. However, to my eyes, the difference is 
> that we don't consider the profile and summation integrated intensities to 
> change as a result of the procedure that ultimately determines 

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

[Gerard Bricogne]

Dear Dirk,

 Aren't you for getting about radiation damage? The n measurements of
the same hkl with the same geometry would not be equivalent, although they
would enable the tracking of radiation damage without the confounding with
absorption effects that comes from considering symmetry-related hkls. I
mentioned that in my second message yesterday.

 The notion of "identical" reflections measurements is problematic for
the same reason that Heraclitus wrote (something like) "You cannot step
twice into the same river". 


 With best wishes,

  Gerard.

--
On Wed, Jul 01, 2020 at 10:46:57AM +0200, Dirk Kostrewa wrote:
> Dear Herman,
> 
> I think, your MPR proposal is a great idea and would like to second it! And
> I would also like to propose that data processing programs just average
> "identical" reflections measured under the same geometry and count them only
> once (*), so that, in the end, we will get a realistic number of truly
> independent measurements.
> 
> Cheers,
> 
> Dirk.
> 
> (*) I don't see a difference between measuring the same reflection with the
> same geometry n-times and measuring it n-times as long (apart from, maybe,
> catching instabilities in the experimental setup). Just averaging such
> "identical" reflections would simplify the subsequent scaling process with
> equivalent reflections that were measured under different geometry.
> 
> On 01.07.20 09:32, Schreuder, Herman /DE wrote:
> > 
> > Dear Bernard and other bulletin board members,
> > 
> > As Gerard mentioned, current data processing programs and table 1’s do
> > not make this distinction, but of course, you are free to ask the
> > community to introduce it.
> > 
> > My proposal to use “measurements per reflections” is not a joke. It
> > exactly describes what is meant by the parameter and it is easily
> > understood even by lay people like journal editors and referees, without
> > the need of lengthy explanations like the ones we have seen in this
> > thread.
> > 
> > I really would like to ask you to consider replacing
> > multiplicity/redundancy/abundancy by MPR. At minimum, it may prevent a
> > thread about completeness of data sets to be hijacked by a discussion on
> > whether use the name multiplicity of redundancy for the number of
> > measurements per reflection.
> > 
> > My 2 cents,
> > 
> > Herman
> > 
> > *Von:* CCP4 bulletin board  *Im Auftrag von
> > *Bernhard Rupp
> > *Gesendet:* Dienstag, 30. Juni 2020 17:50
> > *An:* CCP4BB@JISCMAIL.AC.UK
> > *Betreff:* Re: [ccp4bb] [EXTERNAL] Re: [ccp4bb] number of frames to get
> > a full dataset?
> > 
> > *EXTERNAL : *Real sender is owner-ccp...@jiscmail.ac.uk
> > 
> > 
> > .…but there is a difference whether I measure the same identical hkl
> > over again or ‘preferably in more than one symmetry-equivalent
> > position’, to quote the
> > 
> > IUCr. So do we have a MPSR for the same reflection and a MPRR for the
> > related reflections?
> > 
> > Cacophonically yours,
> > 
> > BR
> > 
> > *From:*CCP4 bulletin board  > > *On Behalf Of *John R Helliwell
> > *Sent:* Tuesday, June 30, 2020 08:36
> > *To:* CCP4BB@JISCMAIL.AC.UK 
> > *Subject:* Re: [ccp4bb] [EXTERNAL] Re: [ccp4bb] number of frames to get
> > a full dataset?
> > 
> > Dear Herman,
> > 
> > I think that MPR is a very neat and tidy, excellent, proposal.
> > 
> > Moreover it uses the word “measurements”, and we are an experimental
> > based science.
> > 
> > I support it.
> > 
> > Great.
> > 
> > Greetings,
> > 
> > John
> > 
> > Emeritus Professor John R Helliwell DSc
> > 
> > On 30 Jun 2020, at 15:10, Schreuder, Herman /DE
> > mailto:herman.schreu...@sanofi.com>>
> > wrote:
> > 
> > 
> > 
> > Dear BB,
> > 
> > Since there does not seem a generally accepted term for the
> > subject of this discussions, and since even the IUCR scriptures do
> > not give any guidance, I would propose to introduce a completely
> > new term:
> > 
> > Measurements per reflection or MPR
> > 
> > This term is politically neutral, should adequately describe this
> > particular statistic and is not associated with entrenched
> > traditions at either side of the Atlantic.
> > 
> > What do you think?
> > 
> > Herman
> > 
> > *Von:*CCP4 bulletin board  > > *Im Auftrag von *John R Helliwell
> > *Gesendet:* Dienstag, 30. Juni 2020 14:34
> > *An:* CCP4BB@JISCMAIL.AC.UK 
> > *Betreff:* [EXTERNAL] Re: [ccp4bb] number of frames to get a full
> > dataset?
> > 
> > *EXTERNAL : *Real sender is owner-ccp...@jiscmail.ac.uk
> > 
> > 
> > Dear Colleagues,
> > 
> > In an effort to break this naming deadlock, and with Massimo and
> > Ian not showing up as yet, I checked the IUCr Dictionary.
> > 
> > “Redundancy“ and “Multiplicity“ are not listed.

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

[Gerard Bricogne]

Dear Ed,

 Concerning your remark that "use of terms redundancy and multiplicity
to describe the same concept is by itself redundant", one could perhaps say
that redundancy is an abstract property of a dataset, while multiplicity is
a numerical attribute. Redundancy is desirable because if some measurements
turn out to be corrupted, there are spare ones to salvage completeness. In
this form it is an aspect of quality, without being in itself a numerical
entity. That property of redundancy is conferred by high multiplicity of
measurement, which is very much a numerical entity. The two terms are
threfore not redundant, but are made so in practice by the shorthand of
giving the numerical attribute the name of the abstract property it gives
rise to.

 Regarding the relation to replication, I can remember Peter Mueller's
book on refinement with SHELX quoting George Sheldrick's point that simply
repeating a measurement is of limited usefulness, because one repeats its
systematic errors, and advocating that what is truly valuable is to make
multiple measurements in conditions such that their systematic errors are
likely to be different. This diversity of conditions gives rise to what he
called "true multiplicity". There is clearly a close affinity between this
concept and that of redundancy viewed as a protection against corrupted
individual measurements.

 The essential thing, though, is not the choice of terminology but the
practical decision of abjuring the pernicious mindset alluded to by the
Subject line of this thread :-) .


 With best wishes,

  Gerard.

--
On Tue, Jun 30, 2020 at 11:19:38AM -0400, Edwin Pozharski wrote:
> Replicate is a good option with its own problems as it can be seen as
> referring to exact copy which multiple measurements clearly aren't. It does
> have an advantage of being the word used by non-crystallographers though.
> 
> As a lame attempt at joke, use of terms redundancy and multiplicity to
> describe the same concept is by itself redundant.
> 
> On Mon, Jun 29, 2020, 7:21 PM Bernhard Rupp 
> wrote:
> 
> > Ah…the rise of the replicants …
> >
> >
> >
> > https://www.youtube.com/watch?v=yWPyRSURYFQ
> >
> >
> >
> > …and don’t forget the and the Voight-Kampff Test results in Table 1.
> >
> >
> >
> > Best, BR
> >
> >
> >
> > *From:* Pierre Rizkallah 
> > *Sent:* Monday, June 29, 2020 15:46
> > *To:* b...@hofkristallamt.org; CCP4BB@JISCMAIL.AC.UK
> > *Subject:* RE: [ccp4bb] number of frames to get a full dataset?
> >
> >
> >
> > You’re missing out on a grand opportunity for iconoclasm here. Try out
> > ‘Degree of Replication’ or ‘Average Replication’ or ‘Replicate Frequency’.
> > Any other offerings!
> >
> >
> >
> > P.
> >
> > ***
> >
> > Dr Pierre Rizkallah, Senior Lecturer Structural Biology
> >
> > Institute of Infection & Immunology, Sir Geraint Evans Building,
> >
> > School of Medicine, Heath Campus, Cardiff, CF14 4XN
> >
> > email: rizkall...@cardiff.ac.ukphone: +44 29 2074 2248
> >
> > http://www.cardiff.ac.uk/people/view/126690-rizkallah-pierre
> >
> >
> >
> > *From:* CCP4 bulletin board  *On Behalf Of *Bernhard
> > Rupp
> > *Sent:* 29 June 2020 23:36
> > *To:* CCP4BB@JISCMAIL.AC.UK
> > *Subject:* Re: [ccp4bb] number of frames to get a full dataset?
> >
> >
> >
> > I think it is time to escalate that discussion to crystallographic
> > definition purists like Massimo or to a logical consistency proponent like
> > Ian who abhors definitional vacuum 
> >
> >
> >
> > Cheers, BR
> >
> >
> >
> > *From:* CCP4 bulletin board  *On Behalf Of *Andreas
> > Förster
> > *Sent:* Monday, June 29, 2020 15:24
> > *To:* CCP4BB@JISCMAIL.AC.UK
> > *Subject:* Re: [ccp4bb] number of frames to get a full dataset?
> >
> >
> >
> > I like to think that the reflections I carefully measured at high
> > multiplicity are not redundant, which the dictionary on my computer defines
> > as "not or no longer needed or useful; superfluous" and the American
> > Heritage Dictionary as "exceeding what is necessary or natural;
> > superfluous" and "needlessly repetitive; verbose".
> >
> >
> >
> > Please don't use the term Needless repetitivity in your Table 1.  It sends
> > the wrong message.  Multiplicity is good.
> >
> >
> >
> > All best.
> >
> >
> >
> >
> >
> > Andreas
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Jun 30, 2020 at 12:03 AM James Holton  wrote:
> >
> > I have found that the use of "redundancy" vs "multiplicity" correlates
> > very well with the speaker's favorite processing software.  The Denzo/HKL
> > program scalepack outputs "redundancy", whereas scala/aimless and other
> > more Europe-centric programs output "multiplicity".
> >
> > At least it is not as bad as "intensity", which is so ambiguous as to be
> > almost useless as a word on its own.
> >
> > -James Holton
> > MAD Scientist
> >
> > On 6/24/2020 10:27 AM, Bernhard Rupp wrote:
> >
> > > Oh, and some of us prefer the word 'multiplicity' ;-0
> >
> > Hmmm…maybe 

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

[Gerard Bricogne]

Dear Bernhard,

 That is true, and the discrepancies between repeated measurements of
the same hkl would have to be parametrised differently from those between
symmetry-related ones (e.g. in terms of radiation damage only, while the
others would also involve absorption effects). However I am not aware that
the existing data processing programs we use actually make and exploit this
distinction.

 Going back to the initial topic of this thread, the main take-home
lesson for Murpholino should be: preoccupations about minimising the number
of frames to get completeness belong to a now obsolete age - instead use the
new paragigm of high-(redundancy/multiplicity) data collection with a low
transmission so that you can spread the dose your crystal can withstand over
the requisite angular range. No matter how you call the "abundance" property
of your final dataset, make sure it is high!

 The case of low symmetry has been mentioned: the extra guidance for
Murpolino is that if you are in P1, you will never get completeness with a
single orientation, so make sure that you use a multi-axis goniometer and
collect data in at least two sufficiently different orientations.


 With best wishes,

  Gerard.

--
On Tue, Jun 30, 2020 at 08:49:53AM -0700, Bernhard Rupp wrote:
> .…but there is a difference whether I measure the same identical hkl over 
> again or ‘preferably in more than one symmetry-equivalent position’, to quote 
> the
> 
> IUCr. So do we have a MPSR for the same reflection and a MPRR for the related 
> reflections?
> 
>  
> 
> Cacophonically yours,
> 
>  
> 
> BR
> 
>  
> 
> From: CCP4 bulletin board  On Behalf Of John R 
> Helliwell
> Sent: Tuesday, June 30, 2020 08:36
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] [EXTERNAL] Re: [ccp4bb] number of frames to get a full 
> dataset?
> 
>  
> 
> Dear Herman,
> 
> I think that MPR is a very neat and tidy, excellent, proposal.
> 
> Moreover it uses the word “measurements”, and we are an experimental based 
> science.
> 
> I support it.
> 
> Great.
> 
> Greetings,
> 
> John 
> 
> Emeritus Professor John R Helliwell DSc
> 
>  
> 
>  
> 
>  
> 
>  
> 
> On 30 Jun 2020, at 15:10, Schreuder, Herman /DE   > wrote:
> 
>  
> 
> Dear BB,
> 
>  
> 
> Since there does not seem a generally accepted term for the subject of this 
> discussions, and since even the IUCR scriptures do not give any guidance, I 
> would propose to introduce a completely new term:
> 
>  
> 
> Measurements per reflection or MPR
> 
>  
> 
> This term is politically neutral, should adequately describe this particular 
> statistic and is not associated with entrenched traditions at either side of 
> the Atlantic.
> 
>  
> 
> What do you think?
> 
> Herman
> 
>  
> 
>  
> 
> Von: CCP4 bulletin board   > Im Auftrag von John R Helliwell
> Gesendet: Dienstag, 30. Juni 2020 14:34
> An: CCP4BB@JISCMAIL.AC.UK  
> Betreff: [EXTERNAL] Re: [ccp4bb] number of frames to get a full dataset?
> 
>  
> 
> EXTERNAL : Real sender is owner-ccp...@jiscmail.ac.uk 
>   
> 
>  
> 
> Dear Colleagues,
> 
> In an effort to break this naming deadlock, and with Massimo and Ian not 
> showing up as yet, I checked the IUCr Dictionary.
> 
> “Redundancy“ and “Multiplicity“ are not listed.
> 
> The more generic term “Statistical Descriptors“ is though and even offers 
> Recommendations:-
> 
> http://ww1.iucr.org/iucr-top/comm/cnom/statdes/recomm.html 
> 
>  
> 
> Point 1, first sentence, fits the various wishes of this thread succinctly, 
> if not in a single word, and even not readily allowing an easy acronym. 
> 
> Greetings,
> 
> John 
> 
>  
> 
> Emeritus Professor John R Helliwell DSc
> 
>  
> 
>  
> 
> 
> 
> 
> 
> On 30 Jun 2020, at 13:11, Phil Jeffrey   > wrote:
> 
> The people that already use multiplicity are going to find reasons why it's 
> the superior naming scheme - although the underlying reason has a lot to do 
> with negative associations with 'redundant', perhaps hightened in the current 
> environment.  And conversely redundant works for many others - Graeme's 
> pragmatic defense of multiplicity actually works both ways - any person who 
> takes the trouble to read the stats table, now exiled to Supplementary Data, 
> knows what it means.  Surely, then, the only way forward on this almost 
> totally irrelevant discussion is to come up with a universally-loathed 
> nomenclature that pleases nobody, preferably an acronym whose origins will be 
> lost to history and the dusty CCP4 archives (which contain threads similar to 
> this one).  I 

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

[Gerard Bricogne]

Dear Phil,

 I would like to make an attempt to not let this question get mired in
exchanges of well-researched linguistic arguments at risk of being drowned
in a cacophony of sound bites :-) .

 You refer to the days of SCALA, at which time data were collected on
CCD detectors, whose lengthy read-out times led to designing data collection
strategies so that they would achieve completeness in the smallest number of
"frames", themselves chosen as thick-sliced as possible while avoiding
angular overlap because of the read-out noise added to each such frame. With
this mindset, measuring again a reflection that had already been measured
could have been viewed as a waste of effort, bringing water to the mill of
interpreting "redundancy" as a sign of sub-optimality. However, looking
again at the CCD datasets collected according to this paradigm, they are
dire! Minimal availability of symmetry-related measurements made internal
scaling fragile, the terrible corner effects in the 3x3 detectors could not
be corrected, and the tracking of radiation damage was beyond hope.

 A lot has happened since, namely pixel-array detectors, fine-sliced
images recorded at low transmission, aiming at recording symmetry-related
reflections "a large number of times" - whatever one ends up calling that.
Far from being superfluous, or "redundant" in the negative sense of the
term, these "abundant" measurements (to coin a phrase) are now recognised as
being absolutely crucial towards the rejection of outliers, a key process in
obtaining high-quality data. This would then bring us back to the positive,
even noble connotation of the term "redundancy", since an abundance of
symmetry-related measurements now allows the detection and rejection of the
dodgy ones. From that perspective, "redundant" is good in the sense Ian
mentioned in relation to aviation equipment: if a few of those measurements
are rotten, you can throw them away and still have some left to do the job.
If you have abundant measurements and just call them multiple, this sense of
allowing rescue in case of failure disappears, and with it an important
aspect of why one should go for strategies that harvest symmetry-related
measurement in high numbers. This is why I ceased to support the standard
term "multiplicity" in conversations with Ian and went along with his choice
of the term "redundancy" in the presentation of STARANISO results.


 With best wishes,

  Gerard.

--
On Tue, Jun 30, 2020 at 02:30:27PM +0100, 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 
> > 

Re: [ccp4bb] Ideas for improving refinement with anisotopic data.

[Gerard Bricogne]

Dear Matthew,

 You seem to have been unlucky with this data collection. STARANISO
would be prepared to see significant data extending to 2.0A along a*, 2.7A
along b*, and 1.7A along c*. The latter limit, however, involves some guess
work via the fitting by an ellipsoid of a cut-off surface that is very much
perturbed by the fact that you have a both a cusp and a truncation by the
detector edges in that direction. Without those, it looks quite probable
that you would have good solid data extending beyond 1.6A - if only you
could redo the experiment in such a way as to actually measure them ;-) .

 As Eleanor said, it is a bad idea to make decisions about data on the
basis of the "downstream" criteria you were mentioning. STARANISO is not
just a numerical program that estimates numbers and suggests some sensible
actions that it will carry out for you: it is also a 3D visualisation tool
that shows you much more about your data and its possible shortcomings than
any Table1-style numbers ever will. If there are indeed deficiencies in the
data, like here, these 3D pictures will often point out what shortcomings in
your experiment are responsible for them. In that case, a new experiment, if
feasible, is always better than any surgery on the deficient data.

 Please feel free to get in touch off-line if you would like more
details, such as patterns of outliers that we have observed.


 With best wishes,

 The STARANISO developers.

--
On Sun, Jun 21, 2020 at 05:33:53PM +0100, Eleanor Dodson wrote:
> *Please* dont throw good 1.8A data for the sake of statistics!
> You should see more detail along certain directions
> You will publish your structure providing honest details of the anisotropy
> (I hope..) but it is the map quality that matters ..
> Eleanor
> 
> On Sun, 21 Jun 2020 at 15:16, Matthew Snee <
> matthew.s...@postgrad.manchester.ac.uk> wrote:
> 
> > Hi everyone.
> >
> > I have an x ray structure that I am finishing up, and there are a few
> > ambiguous regions where the peptide is poorly resolved.
> >
> > The data is highly anisotrophic, and requires truncation to around 2.4A to
> > achieve acceptable merging stats, although there is data in the "good"
> > direction going as high as 1.8-1.9A (determined by merging stats when using
> > elliptical cutoff).
> >
> > I have tried feeding my integration outputs to STARANISO with both the
> > elliptical and spherical cutoffs, but neither produce better results than
> > Xia2 Dials, as both need to be truncated further than 2.3A before they give
> > the same refinement stats (i.e it's best to just let refmac/phenix.refine
> > deal with the anistropy).
> >
> > As I understand it, anisotrophy can lead to loss of high resolution detail
> > because weak observations from the high res shells in the bad direction are
> > down-weighted, So any tricks to improve map quality (or conversely refining
> > data with poor completeness) would be appreciated.
> >
> > I'm not holding out hope that I can deposit anything better than 2.3A, but
> > Improving the maps might really help me with some of these troublesome
> > loops :)
> >
> > Cheers
> >
> > Matthew.
> >
> > Sent from Outlook Mobile 
> >
> > --
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> >
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing 
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at 
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Highest resolution of X-ray / neutron / electron crystallography, cryo EM

[Gerard Bricogne]

Dear Tobias,

 Thank you for identifying the 0.6A resolution structure solved by
electron diffraction as 6KJ3. This is a good, genuine de novo structure
determination using direct methods (SHELXD) on high-resolution data. The
R-values are not flattering (above 30%) but one can't expect too much in
that respect when the data have a mean I/sig()I ~ 4 .

 However, looking at the chemical nature of this molecule, its sequence
is SER-TYR-SER-GLY-TYR-SER, so is it really a macromolecule? It would have
been called a hexapeptide if it had been solved by X-ray crystallography.


 With best wishes,

  Gerard.

--
On Tue, Jun 09, 2020 at 04:11:40PM +0200, Tobias Beck wrote:
> Dear all,
> 
> Thanks a lot! (I should have used the PDB query myself for neutrons, sry,
> my bad)
> 
> As there was a request to share the bioRxiv links, here they are:
> https://www.biorxiv.org/content/10.1101/2020.05.21.106740v1
> https://www.biorxiv.org/content/10.1101/2020.05.22.110189v1
> 
> along with the comment in Nature (which also has both links to the papers
> in the references section):
> https://www.nature.com/articles/d41586-020-01658-1
> 
> So:
> X-ray at 0.48 A
> Neutron at 0.93 A (hybrid with X-ray) or 1.05 A
> Cryo EM 1.25 A
> electron diffraction 0.6 A
> 
> Thanks to all of you!
> 
> Best, Tobias.
> 
> 
> On Tue, Jun 9, 2020 at 3:46 PM Tobias Beck  wrote:
> 
> > Dear all,
> >
> > Thanks for the link to the latest BioRxiv papers! So for cryo EM it is 1.2
> > now. Any numbers for neutron?
> >
> > Best, Tobias.
> >
> > Tobias Beck  schrieb am Di. 9. Juni 2020 um 15:35:
> >
> >> Dear all,
> >>
> >> I was asked by a student what the highest resolution is, for each of the
> >> four methods listed above. Maybe someone has researched the current numbers
> >> previously and would like to share them? For X-ray, I found 0.48 A in the
> >> PDB. For EM method details, the PDB gives me 0.6 A, but it is actually for
> >> electron diffraction. I found a structure with 1.8 A for Cryo EM.
> >>
> >> I am aware that resolution is only one parameter and that high resolution
> >> may not correspond to high data quality. However, maybe someone knows the
> >> record holders, either for biomacromolecules or small molecules or for
> >> both.
> >>
> >> Thanks!
> >>
> >> Best, Tobias.
> >>
> >>
> >>
> >>
> 
> 
> 
> 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/

[ccp4bb] Micro-ED "pushing the frontiers" again ... but which frontiers?

[Gerard Bricogne]

Dear all,

 There have been warnings circulating for quite some time now about the
possible impact of SARS-CoV-2 on the cognitive abilities of patients who
have recovered from Covid-19, and I fear that I have reasons to worry about
possibly having fallen victim to these ... .

 I came across a remarkable piece of work published in 

https://doi.org/10.1016/j.str.2020.01.008

entitled "Experimental Phasing of MicroED Data Using Radiation Damage". I
will follow my notes, in order to ensure that I do not stray even further
from the logic of this paper than I may have done already in writing them
down.

 The subject matter of this article is a famous seven-residue peptide of
exceptional structural stability (which is why it is associated with severe
pathologies), giving radiation-hard microcrystals capable of yielding 1.0
Angs resolution electron diffraction data enabling the solution of this (in
effect, small-molecule) structure by direct methods (PDB code 6CLI) from
such data. A thorough study of radiation damage had been conducted on these
crystals in a previous paper (https://doi.org/10.1016/j.str.2018.03.021),
revealing a detailed picture of site-specific radiation damage affecting in
particular the fully-occupied Zn atom co-crystallised with the peptide.

 The material presented in this new paper is a by-product of the earlier
analysis at 1.0 Angs resolution, whereby two datasets were assembled to
correspond to two substantially different stages of radiation damage (PDB
codes 6CLI and 6CLJ) and were truncated to 1.4 Angs to make direct methods
ineffective. The question is then whether this differential radiation damage
can be exploited as a source of experimental phase information, as has been
done successfully with the so-called RIP method in X-ray crystallography,
the implication being that this could then constitute a generally applicable
method for experimentally phasing electron diffraction data. This ambition
is clearly articulated in the last paragraph of the Introduction: "Here, we
demonstrate that radiation damage from exposure to the electron beam can be
used to solve the phase problem in Micro-ED experiments".

 Enough to get you sitting on the edge of your seat ... .

 The delicate scaling between the two datasets (the first called "low
dose" and the second called "damaged" was accomplished by the DSCA method in
SHELXC so that the difference Patterson showed a single peak, interpreted as
being due to radiation damage on the Zn atom between the two datasets. As we
are in P1 this Zn atom could have been placed at the origin, but for the
sake of comparability, a difference Fourier map was computed by combining
the amplitude differences corresponding to the scaled intensities with the
phases from 6CLI, in which the highest peak corresponded to the position of
the Zn atom in 6CLI. 

 Now the heart of the matter. The maps produced from this single Zn as
sole source of phase information were uninterpretable. Density modification
did not help, presumably because these crystals are close-packed so that
there is no solvent to flatten. The method used instead in order to "solve
the phase problem" (sic) consists in placing atoms in trial positions and
applying some selection criteria to prune out the worst choices. None of
these criteria, however, can dispense with using the wMPE (weighted mean
phase error) from the known structure (6CLI) as a guide. In whatever way it
may be described, therefore, the procedure used seems depends on already
knowing the perfect structure from the previous work at 1.0 Angs resolution.

 This is where I began to question my own sanity, and to wonder whether,
like Rip van Winkle (https://en.wikipedia.org/wiki/Rip_Van_Winkle), I had
somehow fallen into a deep sleep and completely missed a revolution: I was
still clinging to the old-fashioned conception of experimental phasing as
the technique that has the power to produce three-dimensional electron
density maps for macromolecules with total objectivity; now, however, the
new paradigm is clearly that the "experimental" component in experimental
phasing consists in experimenting with the trial placement of atoms while
keeping an eye on the agreement between the corresponding phases and those
for ... the already known structure!

 The problem must obviously lie on my side, since this work has been
published not only in the highly-respected journal "Structure", but even
under the prestigious "Resource" label of this journal, reserved for
articles that are expected "to highlight significant technical advances,
exciting new methods [...] that are of value and interest to the broad
Structure readership and have high impact on the field of structural
biology". 

 I can see that it should indeed have some impact, in the sense of
reassuring Structure readers that if they too happen to have pathologically
stable crystals capable of diffracting to 1.0 Angs resolution (so that, when

Re: [ccp4bb] Jean-Luc Ferrer

[Gerard Bricogne]

Dear all,

 This is very sad news indeed and Jean-Luc's passing away is an enormous
loss for the crystallographic community at large. He and his team showed a
capacity for innovation that stretched over two decades, with the creation
of in situ crystallography (the idea came from Alex McPherson but it was
Jean-Luc who first made it into a production resource on his FIP beamline)
and of the CATS sample changer that adorns most MX synchrotron beamlines
today, later perfected into the versatile multi-purpose G-Rob system. 

 These instrumental innovations entailed very significant software
developments, and it is remarkable that with limited resources and staff
size, his FIP group was able to stand at the forefront of the early creation
of automated data processing pipelines connected to a live data collection
facility.

 Jean-Luc's ground-breaking work on in-situ data collection and the high
level of automation of such experiments (using e.g. his "Crystal Listing")
was the direct precursor of today's High-Throughput Ligand Screening by MX
(e.g. the Diamond VMX-i beamline) and of Synchrotron Serial Crystallography.

 A (very) short anthology of my own favourites among his papers:

https://journals.iucr.org/d/issues/2001/11/00/li0408/index.html
https://journals.iucr.org/j/issues/2004/01/00/hx5003/index.html
https://journals.iucr.org/j/issues/2013/03/00/rg5033/index.html
https://journals.iucr.org/d/issues/2015/08/00/jm5007/index.html

(no attempt here at being exhaustive, nor at writing an obituary ...).

 Jean-Luc's energy, creative power and spirit of enterprise are a
welcome reminder of how much can be achieved by a small team of dedicated
members, even on a road typically dominated by juggernauts. 

 I had immense respect for him, and will miss him terribly. Most trips I
made to Grenoble were an opportunity, to which I always looked forward, to
travel early enough in the day to meet Jean-Luc for dinner and catch up with
his always original and knowledgeable views on "the state of the art" in MX.


 With deepest sympathy for his family, friends and colleagues,

  Gerard.

--
On Thu, Apr 23, 2020 at 10:19:03PM +0200, David Cobessi wrote:
> It is with a deep sadness that we learned the passing away of our dear
> colleague and friend, Dr Jean-Luc Ferrer, on April 21st in Grenoble, after a
> long struggle against his disease.
> Jean-Luc was an internationally known and highly respected scientist in
> protein crystallography.Jean-Luc had led the Synchrotron Group (GSY) at the
> IBS, a research group bridging instrumental and methodological development
> in large research infrastructures and structural biology projects. He was in
> charge of the French national (CRG) beamline FIP-BM30A at the ESRFsince
> 2001. He has always been inventive, dynamic and determined to highlight the
> advantages of synchrotron radiation for protein crystallography. Pioneer in
> the automation of crystallography beamlines, he has been the driving force
> to develop the first sample loader based on a robotic arm with the idea of
> using it directly as a goniometer. This paved the way to “in plate”
> diffraction experiments and its use for intensive ligand screening. He was
> also a co-funder of the NatX-ray company in Grenoble and San Diego and was
> strongly involved in several teaching programs and international workshops.
> Since the shutdown of the ESRF to complete its latest upgrade program,
> Jean-Luc had been in charge to rebuild the FIP beamline in order to provide
> the best service to the community, which will become BM07-FIP2.
> Jean-Luc will be forever missed and remembered.
> David Cobessi, on the behalf of the whole IBS staff and the RéNaFoBiS
> network members
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

-- 

 =======
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===



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

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

[Gerard Bricogne]

Dear all,

 It is a pleasure to be able to end the (GMT) week by calling for a huge
round of applause for the Diamond team, who this afternoon started uploading
a large collection of sets of raw diffraction images (77 as we write but the
upload is still ongoing) for PDB entries that were released two days ago.

 Special thanks to Graeme Winter who organised the upload to Zenodo. The
datasets are collectively accessible via the following link:

https://zenodo.org/search?page=1=20=keywords:%22SARS-CoV-2%20main%20protease%22

 Graeme asked that "major kudos [be given] to Zenodo developers who have
been very responsive with helping us do automated downloads".

 Happy scrutiny and reprocessing of these datasets, and re-refinement of
the associated structures, to all hard-core MX addicts!


 With best wishes,

 Clemens & Gerard.

--
On Thu, Mar 19, 2020 at 10:00:11AM +, John Berrisford wrote:
> Dear all
> 
> The wwPDB OneDep system allows depositors to provide DOIs of raw
> diffraction images during deposition to the PDB and once again
> encourages depositors to provide a DOI for raw images when they have
> submitted.  
> 
> Out of the 9665 X-ray entries that were released in 2019 we have DOI's
> for raw images in 205 of these entries.  
> 
> We would encourage depositors to provide the DOI for their raw images
> when they are available.  
> 
> Regards
> 
> John
> 
> 
> On Mar 19 2020, at 9:48 am, Joel Sussman  wrote:
> 
> > 19-Mar-2020
> > Dear Loes, Peter, Clemens & Gerard,
> > I concur that it is crucial to preserve the original diffraction data
> > and make it available to anyone who would like to use it.
> > As an example, please see the very recent paper by 
> > Nachon et al (2020). "A second look at the crystal structures of
> > Drosophila melanogaster acetylcholinesterase in complex with tacrine
> > derivatives provides Insights concerning catalytic intermediates and
> > the design of specific insecticides" Molecules 25 pii: E1198 
> > [https://www.ncbi.nlm.nih.gov/pubmed/32155891].
> > The study reexamines the original data, with modern software tools,
> > the original data of a paper we published in 2000 (~20 years ago) and
> > revealed features that had not been noticed. Specifically 
> > 1) previously unmodeled density in the native active site can be
> > interpreted as stable acetylation of the catalytic serine. 
> > 2) Similarly, a strong density in the DmAChE/ZA complex, originally
> > attributed to a sulfate ion, is better interpreted as a small molecule
> > that is covalently bound. The complex is reminiscent of the
> > carboxylate/BChE complexes observed in crystal structures of hBChE
> > [Brazzolotto et al, 2012; Nicolet et al, 2003], and demonstrates the
> > remarkable ability of ChEs to stabilize covalent complexes with 
> > carboxylates.
> > Thus, the study demonstrates that updated processing of older
> > diffraction images, and the re-refinement of older diffraction data,
> > can produce valuable information that could not be detected in the
> > original analysis, and strongly supports the preservation of the
> > diffraction images in public data banks.
> > Best regards
> > Joel
> > 
> > Prof. Joel L. Sussman.        joel.suss...@weizmann.ac.il   
> > www.weizmann.ac.il/~joel
> > Dept. of Structural Biology   tel: +972  (8) 934 6309       proteopedia.org
> > Weizmann Institute of Science fax: +972  (8) 934 6312
> > Rehovot 76100 ISRAEL          mob: +972 (50) 510 9600
> > -
> >  
> >  
> >> On 19 Mar 2020, at 11:32, Kroon-Batenburg, L.M.J. (Loes)
> >>  wrote:
> >>  
> >> Dear Gerard,
> >>  
> >> This is a great idea. Of course I am very much in favour of making
> >> available raw diffraction images, and such a virtual workshop could
> >> demonstrate the usefulness of reprocessing raw diffraction data and
> >> structural refinements. I am not at all afraid that archiving of raw
> >> data that are the basis of a scientific paper will have significant
> >> environmental effects: this is minor compared to our everyday use of
> >> cloud services.  And as Graeme mentioned: when archiving raw data
> >> make sure to add sufficient and correct meta data.
> >>  
> >> Best wishes,
> >> Loes
> >>  
> >> ___
> >> Dr. Loes Kroon-Batenburg
> >> Dept. of C

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

[Gerard Bricogne]

Dear colleagues,

Perusal and some initial (re-)refinement of the various SARS-CoV-2 protease
structures in the PDB seems to indicate that that there might be potential
to improve these if refinements could be repeated after some reprocessing
and further analysis of the raw diffraction images, rather than against the
deposited merged data. This statement should in no way be construed as a
criticism of the remarkable achievements of the research groups concerned,
who have been operating under tremendous time pressure, but as an exciting
opportunity to push methods to their limits on a uniquely significant class
of structures.

Another consideration is that the various logistical problems created by
COVID-19 may soon make it increasingly difficult to collect new diffraction
data on potential drug targets relevant to the fight against SARS-CoV-2,
underlining the importance of ensuring that the best results be obtained
from every dataset actually collected, and that the most useful conclusions
be drawn from the analysis of those datasets towards improving the quality
of subsequent data collections. 

On this basis we would like to propose that special efforts be made to grant
public access to the raw image data associated with any SARS-CoV-2 related
structure that is deposited into the PDB. This can be done by (1) archiving
these raw image data using resources such as data.sbgrid.org, zenodo.org,
proteindiffraction.org or any other cloud-based data-sharing service, and
(2) communicating the corresponding DOIs to the wwPDB centres. This idea
could be extended to datasets that investigators would like to offer to
interested methods developers or expert users at the pre-deposition stage.

Experts making use of those raw data would be encouraged to document, in as
much detail as possible, how particular programs or workflows could be used
on those structures/datasets to obtain the best results. This would be a
kind of "virtual workshop", a particularly valuable collective activity at
the present time when several in-person workshops (e.g. RapiData) have been
cancelled and many meetings are in limbo for several months.

The latter activity would benefit from having a centralised facility set up
for the experts to post their results and annotations: we could create such
a facility, but other, larger groups might want to consider doing so. 


With best wishes,

Clemens & Gerard.



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

Re: [ccp4bb] [g...@globalphasing.com: [ccp4bb] An error in the IUCr Online Dictionary of Crystallography] (fwd)

[Gerard Bricogne]

Dear all,

 I don't quite know what to say about the direction in which the initial
topic is getting derailed ... .

 The substance of it is that an official (IUCr) online definition of a
statistic very much relied upon contained both a mathematical error and an
erroneous verbal description, and that this was promptly corrected through
an immediate mobilisation of good will (thank you Randy and Brian).

 Why not leave it at that?


 With best wishes,

  Gerard.

--
On Wed, Mar 11, 2020 at 04:53:25PM +, Eleanor Dodson wrote:
> Am I missing something? He? She? It? Are they now interchangeable?
> 
> On Wed, 11 Mar 2020 at 16:15, Tim Gruene  wrote:
> 
> > Dear Gerard,
> >
> > you are wrong. 'he'  in this context has as much information as 'someone'
> > and
> > 'person'. It does not refer to the sex of the person spoken about.
> >
> > Best regards,
> > Tim
> >
> > On Wednesday, March 11, 2020 4:44:47 PM CET Gerard DVD Kleywegt wrote:
> > > >>>   Sorry to have taken this matter up in such a visible manner: I
> > > >>>   noticed
> > > >>>
> > > >>> this very wrong formula in someone's paper, and that person then
> > told me
> > > >>> where he had found it. Having landed on that page, I didn't know
> > where
> > > >>> to go
> > > For the students:
> > >
> > > "someone" = systematic absence of information = 0 bits
> > > "person" = systematic absence of information = 0 bits
> > > "he" = 1 bit of information!
> > >
> > > --The other Gerard (1 bit of information!)
> > >
> > > **
> > > Gerard J. Kleywegt
> > >
> > >http://xray.bmc.uu.se/gerard   mailto:ger...@xray.bmc.uu.se
> > > **
> > > The opinions in this message are fictional.  Any similarity
> > > to actual opinions, living or dead, is purely coincidental.
> > > **
> > > Little known gastromathematical curiosity: let "z" be the
> > > radius and "a" the thickness of a pizza. Then the volume
> > >  of that pizza is equal to pi*z*z*a !
> > > **
> > >
> > > 
> > >
> > > To unsubscribe from the CCP4BB list, click the following link:
> > > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> >
> > --
> > --
> > Tim Gruene
> > Head of the Centre for X-ray Structure Analysis
> > Faculty of Chemistry
> > University of Vienna
> >
> > Phone: +43-1-4277-70202
> >
> > GPG Key ID = A46BEE1A
> >
> > 
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/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



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

Re: [ccp4bb] [g...@globalphasing.com: [ccp4bb] An error in the IUCr Online Dictionary of Crystallography] (fwd)

[Gerard Bricogne]

Dear Brian,

 Thank you for your reply. I think I could have provided you with the
correct formula myself ;-) but it is indeed correct now. In any case, the
verbal description I gave in my message specified it already.

 The definition in the mmCIF dictionary does look like the source of
that aberrant formula. Is it actually used somewhere as defined? That would
be scary.

 In any case, the one formula in the paper by Jones et al. cited in the
mmCIF description is a real-space R-factor, not a real-space correlation
coefficient. Some sort of monstrous recombination seems to have taken place
between the formula for an R-factor and that for a correlation coefficient,
giving rise to the eye-popping formula I spotted.

 I hope you won't mind if I post this reply to the CCP4BB again, just
for its general entertainment value. It isn't every day that one comes
across this type of typesetting hybridisation :-))) .


 With best wishes,

  Gerard.

--
On Tue, Mar 10, 2020 at 05:39:54PM +, Brian McMahon wrote:
> Dear Gerard
> 
> I've made an amendment following a version of the equation sent
> separately by Randy Read. Please review and let me know if that is
> satisfactory.
> 
> This error seems to have arisen from a transcription of a definition in the
> mmCIF/PDBx dictionary 
> (http://mmcif.pdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_struct_mon_prot.RSCC_all.html)
> which will also need updating. I'll follow that up.
> 
> Thanks for bringing this to our attention.
> 
> Best wishes
> Brian
> 
> 
> On 10/03/2020 17:11, Gerard Bricogne wrote:
> > Dear Brian,
> > 
> >   Sorry to have taken this matter up in such a visible manner: I noticed
> > this very wrong formula in someone's paper, and that person then told me
> > where he had found it. Having landed on that page, I didn't know where to go
> > next. I can't create an account because I do not have an entry in the World
> > Directory of Crystallographers.
> > 
> >   What is the best way of getting this formula corrected?
> > 
> > 
> >   With best wishes,
> > 
> >    Gerard.
> > 
> > - Forwarded message from Gerard Bricogne  -
> > 
> > Date: Tue, 10 Mar 2020 14:15:33 +
> > From: Gerard Bricogne 
> > Subject: [ccp4bb] An error in the IUCr Online Dictionary of Crystallography
> > To: CCP4BB@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://dictionary.iucr.org/Real-space_correlation_coefficient
> > 
> > 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://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1
> > 
> > - End forwarded message -
> > 



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

[ccp4bb] An error in the IUCr Online Dictionary of Crystallography

[Gerard Bricogne]

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://dictionary.iucr.org/Real-space_correlation_coefficient

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://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

Re: [ccp4bb] [ccpem] [3dem] Which resolution?

[Gerard Bricogne]

Dear Sjors,

 I am happy to oblige as the forwarding agent.

 Thank you for continuing this thread: I hope others will do so as well.
These questions are too important to be lost to polemics fatigue ... .


 With best wishes,

  Gerard.

- Forwarded message from Sjors Scheres  -

Date: Mon, 24 Feb 2020 09:48:06 +
From: Sjors Scheres 
Subject: Re: [ccpem] [3dem] Which resolution?
To: cc...@jiscmail.ac.uk

Dear all,

For the newcomers to the cryo-EM field who may be more familiar with X-ray
crystallography and who may not be familiar with this longstanding discussion,
five observations:

1) For large numbers of Fourier components per shell, the FSC=0.143 criterion
is correct and equivalent to the FOM=0.5 criterion used in protein
crystallography. From personal experience in RELION it has worked well in
terms of expected behaviour: alpha-helices become tubular densities around
9-10A, beta-strands become separated at 4.7A, RNA base pairs at 3.6A, etc.

2) Marin is correct that there is an argument for a variable threshold over a
fixed one: when the number of (independent) Fourier components per shell drops
(because the shell lies closer to the origin of the Fourier transform, i.e. is
at lower spatial frequency; or in case of symmetry) one needs to raise the
threshold.

3) However, the amount by how much the threshold changes for typically cases
does, in my opinion, not warrant the language used to make point 2) every
other year or so. Please see here
https://twitter.com/SjorsScheres/status/935182696325763072/ for a plot of the
frequency-dependent behaviour of the 1/2-bit criterion (without symmetry). It
asymptotically approaches 0.172. It was chosen (somewhat arbitrarily) over the
twice as large 1-bit criterion because it was closer to 0.143. However, for a
typical case where the diameter of the particle D is half the box size L (see
Marin's paper here:
https://www.sciencedirect.com/science/article/pii/S1047847705001292)
the
1/2-bit criterion deviates less from 0.172 than 0.172 itself deviates from
0.143 for any Fourier shell that is more than 25 shells away from the origin.
So, for typical single-particle reconstructions with box sizes of say 200-400
pixels used nowadays, and resolutions around say half-Nyquist, the
frequency-dependent threshold will affect the resolution estimate very little,
or at least much less than the arbitrariness in the 1/2-bit criterion itself.
Perhaps someone should propose to multiply the 1/2-bit curve by 0.83 so that
one gets a frequency-dependent threshold that asymptotically reaches 0.143?
;-)

4) There are cases where the frequency-dependent threshold does become more
relevant, e.g. for very low resolutions or when using much smaller box sizes.
The latter occurs for example in sub-tomogram averaging or in (I suspect)
methods some people use for local-resolution calculation.

5) The estimated overall resolution based on whatever FSC-criterion you favour
is just a number. Besides different criteria, there are also subtle
differences in the way different programs calculate the half-maps and correct
for masking effects on the FSC curves. Therefore, don't obsess over how this
number changes in its decimal: what really matters is the quality
(interpretability) of your map.

Hope that helps,
Sjors

PS: I am not on CCP4BB, but I would be OK with someone who is forwarding this
message there.



Marin van Heel wrote:
> 
> Hi Carlos Oscar and Jose-Maria,
> 
> I choose to answer you guys first, because it will take little of my time
> to counter your criticism and because I have long since been less than
> amused by your published, ill-conceived criticism:
> 
> “*/Marin, I always suffer with your reference to sloppy statistics. If we
> take your paper of 2005 where the 1/2 bit criterion was proposed, Eqs. 4
> to 15 have completely ignored the fact that you are dealing with Fourier
> components, that are complex numbers, and consequently you have to deal
> with random variables that have TWO components, which moreover the real
> and imaginary part are not independent and, in their turn, they are not
> independent of the nearby Fourier coefficients so that for computing
> radial averages you would need to account for the correlation among
> coefficients/*”//
> 
> I had seen this argumentation against our (2005) paper in your
> manuscript/paper years back. I was so stunned by the level of
> misunderstanding expressed in your manuscript that I chose not to spend
> any time reacting to those statements. Now that you choose to so openly
> display your thoughts on the matter, I have no other choice than to spell
> out your errors in public.
> 
> All complex arrays in our 2005 paper are Hermitian (since they are the FTs
> of real data), and so are all their inner products. In all the integrals
> over rings one always averages a complex Fourier-space voxel with its
> Hermitian conjugate yielding 

Re: [ccp4bb] [3dem] Which resolution?

[Gerard Bricogne]

Gentlemen,

 Please consider for a moment that by such intemperate language and
tone, you are making a topic of fundamental importance to both the MX and
the EM communities into a no-go area. This cannot be good for anyone's
reputation nor for the two fields in general. It has to be possible to
discuss the topic of "resolution" in a dispassionate way, so as to jointly
gain an improved and shared understanding of the matter, without feeling
implicitly under pressure to support one side or the other. An acrimonious
dispute like this one can only be putting people off getting involved in the
discussion, which is exactly the opposite of what a thread on a scientific
bulletin board should be doing.


 With best wishes,

  Gerard.

--
On Sun, Feb 23, 2020 at 08:15:34AM -0300, Marin van Heel wrote:
> Hi Carlos Oscar and Jose-Maria,
> 
> I choose to answer you guys first, because it will take little of my time
> to counter your criticism and because I have long since been less than
> amused by your published, ill-conceived criticism:
> 
> “*Marin, I always suffer with your reference to sloppy statistics. If we
> take your paper of 2005 where the 1/2 bit criterion was proposed, Eqs. 4 to
> 15 have completely ignored the fact that you are dealing with Fourier
> components, that are complex numbers, and consequently you have to deal
> with random variables that have TWO components, which moreover the real and
> imaginary part are not independent and, in their turn, they are not
> independent of the nearby Fourier coefficients so that for computing radial
> averages you would need to account for the correlation among coefficients*”
> 
> I had seen this argumentation against our (2005) paper in your
> manuscript/paper years back. I was so stunned by the level of
> misunderstanding expressed in your manuscript that I chose not to spend any
> time reacting to those statements. Now that you choose to so openly display
> your thoughts on the matter, I have no other choice than to spell out your
> errors in public.
> 
> 
> 
> All complex arrays in our 2005 paper are Hermitian (since they are the FTs
> of real data), and so are all their inner products. In all the integrals
> over rings one always averages a complex Fourier-space voxel with its
> Hermitian conjugate yielding *ONE* real value (times two)!  Without that
> Hermitian property, FRCs and FSCs, which are real normalised correlation
> functions would not even have been possible. I was - and still am - stunned
> by this level of misunderstanding!
> 
> 
> 
> This is a blatant blunder that you are propagating over years, a blunder
> that does not do any good to your reputation, yet also a blunder that has
> probably damaged to our research income. The fact that you can divulgate
> such rubbish and leave it out there for years for referees to read (who are
> possibly not as well educated in physics and mathematics) will do – and may
> already have done – damage to our research.  An apology is appropriate but
> an apology is not enough.
> 
> 
> 
> Maybe you should ask your granting agencies how to transfer 25% of your
> grant income to our research, in compensation of damages created by your
> blunder!
> 
> 
> 
> Success with your request!
> 
> 
> 
> Marin
> 
> 
> 
> PS. You have also missed that our 2005 paper explicitly includes the
> influence of the size of the object within the sampling box (your: “*they
> are not independent of the nearby Fourier coefficients*”). I remain
> flabbergasted.
> 
> On Fri, Feb 21, 2020 at 3:15 PM Carlos Oscar Sorzano 
> wrote:
> 
> > Dear all,
> >
> > I always try to refrain myself from getting into these discussions, but I
> > cannot resist more the temptation. Here are some more ideas that I hope
> > bring more light than confusion:
> >
> > - There must be some functional relationship between the FSC and the SNR,
> > but the exact analytical form of this relationship is unknown (I suspect
> > that it must be at least monotonic, the worse the SNR, the worse FSC; but
> > even this is difficult to prove). The relationship we normally use
> > FSC=SNR/(1+SNR) was derived in a context that does not apply to CryoEM (1D
> > stationary signals in real space; our molecules are not stationary), and
> > consequently any reasoning of any threshold based on this relationship is
> > incorrect (see our review).
> >
> > - Still, as long as we all use the same threshold, the reported
> > resolutions are comparable to each other. In that regard, I am happy that
> > we have set 0.143 (although any other number would have served the purpose)
> > as the standard.
> >
> > - I totally agree with Steve that the full FSC is much more informative
> > than its crossing with the threshold. Specially, because we should be much
> > more worried about its behavior when it has high values than when it has
> > low values. Before crossing the threshold it should be as high as possible,
> > and that is the "true measure" of goodness of the map. When it 

Re: [ccp4bb] Another difficult MR case

[Gerard Bricogne]

Dear Napoleão,

 If you have such a large number of copies of the molecule in the
asymmetric unit, you should perhaps try and see whether there is some
orientational regularity in the way they are arranged by calculating a
self-rotation function. Any such indication might enable you to filter
solutions on that basis.


 With best wishes,

  Gerard.

--
On Thu, Sep 05, 2019 at 11:03:42PM -0300, Napoleão wrote:
> Dear all,
> Thank you for your kind expert suggestions, and sorry for the late
> reply, I'm still trying all the suggested approaches.
> Some comments:
> - I can't use buccaneer yet, since I'm still working to resolve the
> structure.
> - Robyn Stanfield's suggestion of using Shelxe to try to verify the
> validity of the MR solutions was very helpful. I'm trying it a lot,
> however without success. Thank you Robyn and all Shelx developers!
> - The maps phased with partial molecular replacement solutions look
> reasonable, but do not show any sign of the rest of the molecules or of
> the missing side chains.
> - ContaMiner gave me green lights, so it does not appear to be a
> contaminant (thank you Ivan Shabalin).
> - Similarly, SAUC indicates there is no other PDB with cell parameters
> similar to this data set (thank you Jonathan Cooper).
> - I am currently using EPMR to try to resolve the structure by MR (thank
> you Roger Rowlett).
> - I am not sure if there is translational NCS, as Phil Jeffrey suggested
> despite phenix.xtriage's green lights. I'm not experienced with this
> issue, so I'm sending the log file to Randy Read as he kindly offered to
> help.
> 
> I think one of my problems is that the AU is big (at least to me),
> apparently containing from 9 to 12 copies of my protein, so the MR
> solutions contain less than 10% of the scatters in the AU.
> Maps look good when I refine one chain of the MR solutions in Phenix
> (blue maps over most of the protein, with reasonable main chain
> continuity and very few green or red blobs), but the R values are 0.50
> and I can't see any feature suggesting the solution is good (like a
> well-defined new side chain).
> I will keep trying.
> 
> Thank you all again! And please let me know if any ideas cross your wise
> minds.
> Regards,
> Napo
> 
> Em 2019-08-30 06:29, Randy Read escreveu:
> 
> > Dear Napoleão, 
> > Yes, I agree with Phil that it looks like a case where there *is* 
> > translational NCS but it's not being used by Phaser, either because it 
> > wasn't automatically detected (native Patterson peak just under the default 
> > limit? more than one off-origin Patterson peak?) or because Phaser was told 
> > to ignore tNCS.  You should look in detail at the relevant section of the 
> > logfile, and manually override Phaser's automated decision if you think 
> > there's good evidence for tNCS.  I would say that, as Phil noted, the fact 
> > that two molecules are in basically the same orientation separated by a 
> > translation is pretty strong evidence.  In particular, the fact that 
> > placing the second molecule in the same orientation gave such a large 
> > increase in both LLG and TFZ is strong evidence: this tells us that having 
> > two molecules in the same orientation (even if they're the wrong molecule 
> > or in the wrong orientation) explains some feature of the data, i.e. the 
> > modulation caused by tNCS. 
> > 
> > I'd be happy to look at the log file for you if you find it hard to 
> > interpret. 
> > 
> > Best wishes, 
> > 
> > Randy Read
> > 
> > On 29 Aug 2019, at 17:24, Phil Jeffrey  wrote: 
> > 
> > Are you *sure* there's no translational NCS ?
> > 
> > For example your first molecular replacement solution out of Phenix shows
> > 
> > EULER  293.6   27.7  288.7
> > FRAC -0.02  0.02  0.02
> > (that's "first molecule at origin in P1")
> > 
> > and
> > 
> > EULER  294.0   27.9  288.8
> > FRAC -0.37  0.02  0.02
> > 
> > which is essentially the same orientation, and a translation down one 
> > crystallographic axis (a*)
> > 
> > And this suggests to me that either Xtriage or Phaser is missing something 
> > here.  Does Phaser find translational NCS in its initial data analysis ?  
> > Unmodeled translational NCS could cause significant problems with the 
> > molecular replacement search.
> > 
> > Phil Jeffrey
> > Princeton
> > 
> > On 8/29/19 11:28 AM, Napoleão wrote:
> > Deal all,
> > Sorry for the long post.
> > I have a data set obtained from a crystal produced after incubating a 
> > protease with a protein which is mostly composed by an antiparallel beta 
> > sheet. I have tried numerous approaches to solve it, and failed. Molecular 
> > replacement using Phaser, and the protease or the protein as a template 
> > yields no solution. However, molecular replacement using only part of the 
> > beta sheet yields LLG=320 TFZ==28.0 (see below).
> > The apparently good data extends to 1.9 A, as processed by XDS, and the 
> > space group is P1 (pointless agree). XDS info below:
> > SPACE_GROUP_NUMBER=1
> > 

Re: [ccp4bb] AW: [EXTERNAL] [ccp4bb] Questionable Ligand Density: 6MO0, 6MO1, 6MO2

[Gerard Bricogne]

Dear Kay and colleagues,

 It is possible to extend the inspection of data associated to a PDB
entry beyond Table 1 by means of the PDBpeep server available at 

http://staraniso.globalphasing.org/cgi-bin/PDBpeep.cgi

Doing so for these three entries shows that while 6MO2 has a rather normal
3D distribution of ) and , both 6MO0 and 6MO1 show a strange
pattern for these two quantities, where the iso-surfaces are pinched towards
the origin along the c* axis - perhaps, indeed, an indication that the space
group is wrong and that the point group is 3 rather than 32 (?). It might be
something else, but there is a definite anomaly in the 3D distributions of
these two statistics.


 With best wishes,

  Gerard.

--
On Fri, Jul 19, 2019 at 06:07:33PM +0100, Kay Diederichs wrote:
> Hi Tristan et al,
> 
> before people invest their time into re-refining a model against the 
> deposited data, I'd suggest that these data are dubious - see table S3 in 
> https://pubs.acs.org/doi/suppl/10.1021/jacs.9b02505/suppl_file/ja9b02505_si_001.pdf
>  ! The data processing statistics look "surprising" to me: "Rsym or Rmerge" 
> values are unexpectedly high, and the high-resolution cutoffs for 2 of the 3 
> structures are too low. Maybe the space group is wrong? With such data, 
> ligand density cannot expected to be meaningful, I'd say.
> In my eyes, the authors should be asked for the raw data images, and these 
> should be reprocessed before re-refinement.
> 
> best,
> Kay
> 
> On Fri, 19 Jul 2019 17:05:21 +0100, Tristan Croll  wrote:
> 
> >I couldn't resist doing a little playing with 6mo0 in ISOLDE. The
> >sequence past Gly1151 is wrong - after jumping a small gap (density
> >clearly indicates a single missing residue here), it continues on from
> >1165. Corrected the following sequence to GVVTRS, deleted the ligands,
> >did some basic energy minimisation and cleaning up of obvious local
> >problems, reset the B-factors and refined in Phenix.refine. Rwork/Rfree
> >28/32, MolProbity score 2.14 (vs. 3.6 originally). No sign of anything
> >like the ligand in the difference density (just a small blob in the
> >active site). Some other oddities make me suspect a number of point
> >mutations from the assigned sequence (not register errors - the
> >surrounds are quite clear). I'm particularly intrigued by residues 48-71
> >- this stretch appears to link seamlessly head-to-tail with its own
> >symmetry copy, forming a seemingly-continuous chain snaking through the
> >crystal. Can't make head nor tail of that. A decidedly odd structure...
> >but I agree with you that the ligand doesn't seem supported by the
> >density.
> >
> >Best regards,
> >
> >Tristan
> >
> >On 2019-07-19 14:46, herman.schreu...@sanofi.com wrote:
> >> Hi Rhys,
> >>
> >> There is definitively some density present for a ligand, but the
> >> active site region looks completely misfitted, and the ligand density
> >> may also belong to unfitted protein residues. One first needs to get
> >> the protein chain right, and should then look if there would still be
> >> density available to fit the ligand.
> >>
> >> Best,
> >>
> >> Herman
> >>
> >> VON: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] IM AUFTRAG VON
> >> Rhys Grinter
> >>  GESENDET: Freitag, 19. Juli 2019 15:22
> >>  AN: CCP4BB@JISCMAIL.AC.UK
> >>  BETREFF: [EXTERNAL] [ccp4bb] Questionable Ligand Density: 6MO0, 6MO1,
> >> 6MO2
> >>
> >> EXTERNAL : Real sender is owner-ccp...@jiscmail.ac.uk
> >>
> >> Hi All,
> >>
> >> I was chatting with a colleague during a recent synchrotron visit and
> >> they'd recently come across some ligand/drug bound structures
> >> associated with a paper recently published in a high impact factor
> >> journal.
> >>
> >> They had pulled the associated SFs from the PDB and found that the
> >> electron density associated with these ligands didn't match that
> >> reported in the paper and certainly wasn't sufficient to model the
> >> alleged ligand.
> >>
> >> I also pulled the structure factors and after refinement in the
> >> presence/absence of the alleged ligand I also feel that the density
> >> present does not warrant modelling of the ligand.
> >>
> >> I was hoping that the community might be able to give me an outside
> >> opinion on these datasets (PDB IDs: 6MO0, 6MO1, 6MO2) and if the
> >> problem associated with the data is verified, provide some advice on
> >> how to proceed.
> >>
> >> This isn't the first occasion I've seen ligand bound structures with
> >> questionable density deposited in association with papers in well
> >> respected journals. Despite improvements to validation I feel that
> >> this problem is widespread.
> >>
> >> Best Regards,
> >>
> >> Rhys
> >>
> >> --
> >>
> >> Dr Rhys Grinter
> >>
> >> NHMRC Postdoctoral Researcher
> >>
> >> Monash University
> >>
> >> +61 (0)3 9902 9213
> >>
> >> +61 (0)403 896 767
> >>
> >> -
> >>
> >> To unsubscribe from the CCP4BB list, click the following link:
> >>  

Re: [ccp4bb] resolution

[Gerard Bricogne]

Dear Sam,

 If you have a P1 space group and your dataset was collected in a single
orientation, you will have a great big gaping cusp in it.

 I would suggest that you submit your full dataset to the STARANISO
server at  

  http://staraniso.globalphasing.org/cgi-bin/staraniso.cgi

and take into consideration the distribution of the blue dots. It can be
horrifying: for instance, take a look at 

http://staraniso.globalphasing.org/cgi-bin/RLViewer_PDB_scroll.cgi?ID=6oa7 . 

 The rationale for reducing the resolution at which refinement is done
would be to reduce the proportion (and hence impact) of the systematically
missing data in the cusp, as this gets rapidly worse at high resolution.

 The real remedy is to collect data again, this time in at least two
orientations that are different enough to fill each other's cusps at the
highest resolution. Then you will be able to enjoy the full diffraction
limit (2.0A or better) that your crystal seems willing to give ;-) .


 With best wishes,

  Gerard.

--
On Fri, Jul 05, 2019 at 09:48:35PM +0800, Sam Tang wrote:
> Dear all
> 
> Hello again
> 
> Thanks a lot for the numerous input.
> 
> I received a dataset which was processed to 2.4A but refined to 3A -- this
> was the background I raised this question in the first place. Then I looked
> at the aimless statistics. At 2.4A the high resolution bin CC1/2 0.626,
> I/sigI 2.0, Completeness 84.6, Multiplicity 1.7 (P1 spacegroup).  I suspect
> the reason for the refinement resolution limit to be set at 3 A was simply
> due to better Rw/Rf (0.236/0.294 at 3A; 0.284/0.341 at 2.4A).
> 
> Based on these information am I justified to say that data quality at 2.4 A
> was suboptimal? In this case do you think refining at a (much) lower
> resolution is acceptable?
> 
> Best regards
> 
> Sam
> 
> On Fri, 5 Jul 2019 at 13:43, Sam Tang  wrote:
> 
> > Hello everyone
> >
> > Sorry for a naive question. Is there any circumstances where one may wish
> > to refine to a lower resolution? For example if one has a dataset processed
> > to 2 A, is there any good reasons for he/she to refine to only, say 2.5 A?
> >
> > Thanks!
> >
> > Sam Tang
> >
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1



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

Re: [ccp4bb] Problematic on-line reference

[Gerard Bricogne]

Dear Tomas,

 Thank you very much for your help! Neil Paterson, from the
Diamond Light Source, had just sent me the same result a moment ago
and explained the magic of consulting this Web archive. I won't forget
this very useful trick.

 This has salvaged my on-line reference :-))) - thank you again to
both of you.


 With best wishes,

  Gerard.

--
On Mon, Apr 15, 2019 at 05:23:46PM +0100, Tomas Malinauskas wrote:
> Dear Gerard,
> you can find a copy of the page here:
> https://web.archive.org/web/20110624033607/http://ccp4wiki.org/~ccp4wiki/wiki/index.php?title=Scaling_experimental_intensities_with_Scala
> Hope that helps,
> Tomas
> 
> On Mon, Apr 15, 2019 at 4:19 PM Gerard Bricogne  
> wrote:
> >
> > Dear all,
> >
> >  In a recently completed piece of writing I used as a reference
> > the following on-line material:
> >
> > http://ccp4wiki.org/~ccp4wiki/wiki/index.php?title=Scaling_experimental_intensities_with_Scala#Corner_corrections
> >
> > that I had found in 2017.
> >
> >  Now that I have to quote, at the proof-checking stage, an access
> > date for this reference, I find that it is no longer available.
> >
> >  Would anyone know of the whereabouts of this material? Or of
> > other, more recent and/or more permanent material on the same subject
> > (i.e. corner effects in 3x3 CCD detectors)?
> >
> >  Any help will be greatly appreciated.
> >
> >
> >  With best wishes,
> >
> >   Gerard.
> >
> > --
> >  ===
> >  * *
> >  * Gerard Bricogne g...@globalphasing.com  *
> >  * *
> >  * Global Phasing Ltd. *
> >  * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
> >  * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
> >  * *
> >  ===
> >
> > 
> >
> > 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

[ccp4bb] Problematic on-line reference

[Gerard Bricogne]

Dear all,

 In a recently completed piece of writing I used as a reference
the following on-line material:

http://ccp4wiki.org/~ccp4wiki/wiki/index.php?title=Scaling_experimental_intensities_with_Scala#Corner_corrections

that I had found in 2017.

 Now that I have to quote, at the proof-checking stage, an access
date for this reference, I find that it is no longer available.

 Would anyone know of the whereabouts of this material? Or of
other, more recent and/or more permanent material on the same subject
(i.e. corner effects in 3x3 CCD detectors)?

 Any help will be greatly appreciated.


 With best wishes,

  Gerard.

--
 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===



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

Re: [ccp4bb] Question about the electron density maps (.ccp4) in PDBe

[Gerard Bricogne]

Dear Sen,

 Our messages just crossed ... .

 With best wishes,

  Gerard.
--
On Tue, Mar 05, 2019 at 11:32:01AM -0500, Yao, Sen wrote:
> Dear Gerard,
> 
> Thank you for your reply. I totally agree with you.
> 
> The average value of the 2mFo-DFc map should be zero, and from my
> observation, most of them are a very small number (<0.001) that can be
> viewed as zero practically. As Pavel mentioned, phenix.f000 will give you
> F(0,0,0) value, but I don't see that information stored and easily
> calculated from .ccp4 data.
> 
> Your solution to add up the electrons in the model and divide by the number
> of voxels related to the model is in essence what I did to aggregate the
> atoms into chains. The problem is determining the voxels to include which
> require the radii determined for each atoms. For that I optimized the radii
> for each atom type using the criteria that all atoms need to include a
> significant number of electrons and give a consistent result across the
> whole PDB structures.
> 
> And with all that, I got this ~1/3 value of the theoretical number of
> electrons. I guess what I have to do is to use this ratio and convert them
> back to an actual number of electron meaning.
> 
> Thank you all for the input!
> 
> Cheers,
> Sen
> 
> 
> On Mon, Mar 4, 2019 at 1:21 PM Gerard Bricogne 
> wrote:
> 
> > Dear Sen,
> >
> >  I may be unaware of special features of these maps, but if they
> > are computed in conventional ways, they lack an F000 term. Therefore
> > the average value of the 2mFo-DFc map is zero, just as if it was a
> > difference map. This may explain why you do not find all the electrons
> > you would be expecting. To get this right, you would need to add that
> > F000 term to the set of Fourier coefficients going into the
> > calculation of the map. You can get a pretty satisfactory F000 value
> > by taking it from the Fourier transform of the model density, and
> > applying the appropriate scale factor. Unfortunately not all structure
> > factor programs will give you that F000. Instead, then, you can add
> > the numbers of electrons for all the atoms of your model in the unit
> > cell, put it on "map scale", divide it by the number of voxels in that
> > unit cell, and add it to all the map values in all the voxels you
> > examine.
> >
> >  In any case, the use of a zero-mean map would be the cause of
> > your 1/3 factor.
> >
> >  Apologies to the PDBe if they have already thought of that and
> > are including the F000 (or average number of electrons per voxel) into
> > the calculation of their maps - I didn't see any sign that this was
> > being done.
> >
> >
> >  With best wishes,
> >
> >   Gerard.
> >
> > --
> > On Mon, Mar 04, 2019 at 10:36:11AM -0500, Yao, Sen wrote:
> > > Hi all,
> > >
> > > I have been using the electron density maps available on the PDBe website
> > > to run some analysis. And I run into this question that I hope that I can
> > > get some help from the community.
> > >
> > > In the ccp4 format, the electron density is represented as a 3-d array
> > map,
> > > with each number corresponds to the density value of a voxel in real
> > space.
> > > If I add all voxel densities around an atom together and divided it by
> > the
> > > number of electrons of that atom, in theory it should give me a ratio
> > with
> > > the unit Å-3 (angstrom to the power of -3), and this ratio should be
> > > inversely related to the voxel volume. (Correct me if I am wrong here.)
> > > However, after I got this ratio for each atom, aggregated it into chains
> > > and calculated a median, and then compared the chain median to the voxel
> > > volume over all PDB structures with electron density available, they
> > show a
> > > slope of ~1/3 instead of expected 1 (see attached link). That is, almost
> > > all the values in the electron density maps are only about 1/3 of
> > > represented electrons.
> > >
> > >
> > https://drive.google.com/file/d/1K_3uxZfUPuTdH1DtKJgKHLRUA5NHTVPB/view?usp=sharing
> > >
> > >
> > > So my question is, is there a conversion or scaling factor that PDBe uses
> > > to generate the ccp4 files? If so, is that information stored in the ccp4
> > > files or anywhere else? And if not, why do I observe this 1/3 r

Re: [ccp4bb] Question about the electron density maps (.ccp4) in PDBe

[Gerard Bricogne]

Dear Sen

On Tue, Mar 05, 2019 at 11:05:26AM -0500, Yao, Sen wrote:
> Thank you Ian! The response is really informative.
> 
> I am aware that electron density is a point sample. And multiply it by the
> voxel volume is an estimated average. I do have a normalization step in my
> calculation that should average this potential error out. It would be nice
> to sample it finely, but given that I am working with just the ccp4 files
> available, how they sampled it is what went directly in my calculations.
> Hope this clarifies your concerns.
> 
> For the second issue, I've also notice that as well and did actually
> optimize the radii for each atom type based on the criteria that they need
> to include a significant number of electrons across the whole PDB
> structures. Voronoi polyhedra is probably another way to do it; as for my
> calculation, I think once the density is below 1.5 sigma (for 2mFo-DFc),
> there is not much information gain to keep extending the radii around an
> atom.

 The term "1.5 sigma" says it all: this "sigma" a root-mean-square
deviation from the average density in the map, which is zero because
of the absence of the F000 term in the Fourier synthesis used to
compute that map. To get the pointwise density you want, you have to
add back that missing true mean density per voxel, i.e. on absolute
scale the total number of electrons in the unit cell divided by the
number of voxels in that unit cell.

> And for the first issue you mentioned, it is a very interesting point. I
> don't have anything to directly correct for that on an atom level. But I do
> aggregate atoms into chains (sum of all density together of all atoms on a
> chain and divide by the total number of voxels involved). Maybe that will
> account for potential atomic misplacement? But for the density being only
> part of the true density, I am not sure there is an easy way to account for
> that from ccp4 data only.
> 
> Best,
> Sen
> 
> 
> On Mon, Mar 4, 2019 at 12:43 PM Ian Tickle  wrote:
> 
> >
> > Hi Sen
> >
> > If you multiply the electron density in a voxel by the voxel volume you
> > should get an estimate of the number of electrons contained in that voxel,
> > and then you can add up the numbers of electrons in all the voxels occupied
> > by an atom to get the total number of electrons in that atom, which is
> > basically the same as what you are saying.
> >
> > However note that the electron density is a point sample: it's not the
> > average density in the voxel, so the above calculation won't be quite
> > accurate, depending on the 'smoothness' of the density.  This is like the
> > error in an integral by use of Simpson's rule.  To be sure of accounting
> > for all the density you need to sample it finely, say not more that Dmin/4.
> >
> > There are two more issues here: first the atomic positions are never
> > error-free which reduces the contribution to the density by the factor D in
> > the expression 2mFo-DFc (or mFo for centric phases) for the map
> > coefficients.  So if the errors were sufficiently large D would tend to
> > zero and you would get no density at all!  The density that you see is
> > really only that part of the true density for which there is evidence in
> > the experimental data.
> >
> > Second, what exactly do you mean by "add all voxel densities around an
> > atom"?  The electron density could easily extend 2 Ang. from an atomic
> > centre, depending on the atom's finite size (represented by the form
> > factor), its thermal motion (B factor) and series termination effects
> > (resolution).  So if you don't go out far enough you will fail to account
> > for some fraction of the electron count.  The problem is of course you
> > can't go so far as to overlap bonded atoms which will be well within 2 Ang.
> > distance.  The standard method of dealing with this is to represent 'soft'
> > atoms (where the distance between atoms may be less than the sum of their
> > radii) as Voronoi polyhedra (like the packing of soap bubbles!).  Is that
> > how you handled it?
> >
> > Cheers
> >
> > -- Ian
> >
> >
> > On Mon, 4 Mar 2019 at 15:47, Yao, Sen  wrote:
> >
> >> Hi all,
> >>
> >> I have been using the electron density maps available on the PDBe website
> >> to run some analysis. And I run into this question that I hope that I can
> >> get some help from the community.
> >>
> >> In the ccp4 format, the electron density is represented as a 3-d array
> >> map, with each number corresponds to the density value of a voxel in real
> >> space. If I add all voxel densities around an atom together and divided it
> >> by the number of electrons of that atom, in theory it should give me a
> >> ratio with the unit Å-3 (angstrom to the power of -3), and this ratio
> >> should be inversely related to the voxel volume. (Correct me if I am wrong
> >> here.) However, after I got this ratio for each atom, aggregated it into
> >> chains and calculated a median, and then compared the chain median to the
> >> voxel 

Re: [ccp4bb] Question about the electron density maps (.ccp4) in PDBe

[Gerard Bricogne]

Dear Sen,

 I may be unaware of special features of these maps, but if they
are computed in conventional ways, they lack an F000 term. Therefore
the average value of the 2mFo-DFc map is zero, just as if it was a
difference map. This may explain why you do not find all the electrons
you would be expecting. To get this right, you would need to add that
F000 term to the set of Fourier coefficients going into the
calculation of the map. You can get a pretty satisfactory F000 value
by taking it from the Fourier transform of the model density, and
applying the appropriate scale factor. Unfortunately not all structure
factor programs will give you that F000. Instead, then, you can add
the numbers of electrons for all the atoms of your model in the unit
cell, put it on "map scale", divide it by the number of voxels in that
unit cell, and add it to all the map values in all the voxels you
examine.

 In any case, the use of a zero-mean map would be the cause of
your 1/3 factor. 

 Apologies to the PDBe if they have already thought of that and
are including the F000 (or average number of electrons per voxel) into
the calculation of their maps - I didn't see any sign that this was
being done.


 With best wishes,

  Gerard.

--
On Mon, Mar 04, 2019 at 10:36:11AM -0500, Yao, Sen wrote:
> Hi all,
> 
> I have been using the electron density maps available on the PDBe website
> to run some analysis. And I run into this question that I hope that I can
> get some help from the community.
> 
> In the ccp4 format, the electron density is represented as a 3-d array map,
> with each number corresponds to the density value of a voxel in real space.
> If I add all voxel densities around an atom together and divided it by the
> number of electrons of that atom, in theory it should give me a ratio with
> the unit Å-3 (angstrom to the power of -3), and this ratio should be
> inversely related to the voxel volume. (Correct me if I am wrong here.)
> However, after I got this ratio for each atom, aggregated it into chains
> and calculated a median, and then compared the chain median to the voxel
> volume over all PDB structures with electron density available, they show a
> slope of ~1/3 instead of expected 1 (see attached link). That is, almost
> all the values in the electron density maps are only about 1/3 of
> represented electrons.
> 
> https://drive.google.com/file/d/1K_3uxZfUPuTdH1DtKJgKHLRUA5NHTVPB/view?usp=sharing
> 
> 
> So my question is, is there a conversion or scaling factor that PDBe uses
> to generate the ccp4 files? If so, is that information stored in the ccp4
> files or anywhere else? And if not, why do I observe this 1/3 ratio pretty
> consistently across the whole PDB?
> 
> I would really appreciate any insights on this matter. Thank you!
> 
> Sincerely,
> Sen
> 
> -- 
> 
> Sen Yao, PhD
> Center for Environmental and Systems Biochemistry
> Markey Cancer Center
> University of Kentucky, Lexington KY
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1

-- 

 =======
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===



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

[ccp4bb] Updated deposition instructions for STARANISO-treated diffraction data

[Gerard Bricogne]

Dear all,

 In response to numerous enquiries from users, and after many
discussions, we have substantially revised our recommendations on the
deposition of intensities and structure factors into the PDB, posted
on the STARANISO server at 

  http://staraniso.globalphasing.org/deposition_about.html

 We hope that this will be found helpful by users who have seen
beneficial effects in using data treated by STARANISO and want to
deposit these data along with their structure. The procedure we are
recommending should be accepted by at least the PDBe.

 Please do not hesitate to send us feedback and/or further
questions if you still find some points unclear or encounter any
difficulties in this process.


 With best wishes,

 The STARANISO developers.



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

[ccp4bb] Upgrades to the STARANISO and PDBpeep servers

[Gerard Bricogne]

Dear CCP4BB readers,

 We are pleased to announce a number of improvements in the
STARANISO and PDBpeep servers, respectively situated at 

 http://staraniso.globalphasing.org/cgi-bin/staraniso.cgi

and 

 http://staraniso.globalphasing.org/cgi-bin/PDBpeep.cgi.


 We had received many requests for a stereo capability in the 
RLViewer that is common to both servers. This would however have been
overly complicated to implement. To achieve the same purpose of
supporting constant 3D perception, we have made the points depth-cued
and have added 'Rock' & 'Roll' options, with speed and amplitude
selection (see help info for new bindings of 'q', 'r' and arrow keys).


 Further upgrades to the RLViewer are as follows:

 * addition of a Get/Set orientation transfer facility, to provide
identical orientations between views in different browser windows;

 * addition of more function buttons to allow colour selection for
each scene independently;

 * addition of a new colour (9: pink) to mark up 'red' points with
I/sd(I) > 3 (complement function key binding changed from '9' to 'n');

 * addition of a date stamp to Javascript sources to avoid caching
problems;

 * change from frames to scrolling windows, and addition of new
function buttons as alternatives to keyboard shortcuts (mostly for the
benefit of tablet & smartphone users!).


 STARANISO-specific changes:

 * Changed XDS profile-correlation levels to match corresponding
mean I/sd(I) levels;

 * Added a recommended citation to the FAQ.


 PDBpeep-specific change:

 * Added option to select from multiple deposited datasets (for
usage instructions, see under the PDB code entry box).


 We would like to thank all the users of these two servers (the
STARANISO server is close to reaching 3,000 successful submissions in
2018) and especially those who have sent us feedback.


 We wish everyone a happy holiday season and hope to continue to
enhance your perception and understanding of diffraction anisotropy
(and of data quality in general) throughout the New Year by means of
these two servers.



The STARANISO developers.



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

Re: [ccp4bb] R-merge is too high !!

[Gerard Bricogne]

Dear Zhang,

 You mention being advised to submit your data to the STARANISO
server, but from your description of your response, it seems that you
submitted it instead to the UCLA Diffraction Anisotropy Server.

 Your case appears to be an instance where the UCLA server gives
puzzling results: from the blue and green curves given in its output,
there would seem to be substantial anisotropy, considering that the
green curve dives down to the F/sig(F) significance threshold value of
3.0 at 3.1A resolution, while the blue one keeps going and ends up
well above the green one at that same resolution - unless of course
the origin for the vertical F/sig(F) axis is not zero but 2.999 :-) .

 It would be interesting to see what you get with the STARANISO
server itself: it is easy to use, and you can find it at 

http://staraniso.globalphasing.org/


 With best wishes,

 The STARANISO developers.

- 
Date: Tue, 16 Oct 2018 16:52:40 +0800
From: Zhang Foggy 
Subject: Re: [ccp4bb] R-merge is too high !!
To: CCP4BB@JISCMAIL.AC.UK

Dear All,

Sorry for the late reply. I was out of town in last two weeks.

Again, thanks for your kindly comments, and here are the summary for the
additional comments and my responses:

1. Summary:

The high value of the R-merge might be due to the wrong orientation matrix
(beam center), anisotropic, potential sample vibration, or radiation damage.

The suggestions are checking the orientation matrix and beam position, and
use pointless "centre" option in XDS to correct the center, use only
partially frames to do integration,  or  avoid sample vibration.

2. Responses to the comments:

(1). Dr. Klaus Futterer suspected the data has large variation during the
lattice parameters refinement or orientation matrix coefficients during
integration, and suggested to determine the orientation matrix in XDS with
all frames or only part (10-20%) of the frames with clear diffraction
spots, and then integrate the frames without floating the lattice
parameters.

Response: Thanks for the suggestion, I will work on this soon and see what
is going to happen.

(2). Dr. Eric Montemayor suspected the data is anisotropic, and suggested
to submit the data to the staraniso server.

Response: I submit the data to the anisotropic server (
http://services.mbi.ucla.edu/anisoscale/), and you can see in the
attachment that my data only has low and mild anisotropy.

[image: anisotropy.png]

(3). Dr. James Holton suspected that current results could be caused by
sample vibration due to particular crystal and loop shape (reference: J.
Appl. Cryst., 2008, 41, 1122). (I) Ways to diagnose sample vibration: (a)
Look at the highest intensity bin to see Rmerge for the brightest spots;
(b) Take a series of "stills" or at least the same narrow rotation about
3-10 times in a row from the same crystal with the same starting phi each
time, integrate the images as usual, and look at the variation (Rmerge) for
each hkl individually. Then plot the variation vs. location on the
detector. If we see swaths of reciprocal space with high variation while
others low, and the orientation of the swaths is not related to the phi
axis, then we know we've got vibration issues. (c) Look at other data sets
from the same instrument. If the low-angle Rmerge in P1 of the dataset
stands out, then it was probably sample vibration. (II) Ways to solve this
issue (a) adjust the flow rate of the cold stream; (b) shore-up the mounts;
(c) coat the twisty loop neck with epoxy before mounting the crystal; (d)
use loop and base (curved) from MiTeGen (MiTeGen must pay the advertising
fee!). (III) If Rmerge is high like I am seeing here I should definitely
inform whomever is maintaining the instrument I used that there is a
problem.

Response: Thanks for the suggestion. Actually, I have discussed with the
beamline stuff to argue this potential issue. However, (a) after collecting
this set of data, I do collect data from other crystals grown from
different protein, and the R-merge looks fine. (b) I have collected four
sets of data again four months later, and all of them show similar high
R-merge value.  The stuff thought the high R-merge value of the crystals
from only this type of protein should not due to the hardware of the
synchrotron nor the loop itself.

(4). Dr. Thomas Cleveland mentioned that he had a similar situation before,
and this could be caused by a misindexing of the diffraction origin by +/-
1 due to a slightly incorrect beam center. He suggested to use the
pointless "centre" option in XDS to do a search for the correct center just
like the example at
https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Pointless, and
then use the INDEX_ORIGIN parameter to specify the correct origin, and
reintegrate the data.

Response: Thanks for the suggestion, I will work on this soon and see what
is going to happen.

(5). Dr. Kajander, Tommi A asked that if I can see R-merge difference if I
only process a sector 

Re: [ccp4bb] To post to ccp4bb...

[Gerard Bricogne]

I would favour the PEG interpretations. PEG-y snakes like to nestle
against hydrophobic patches, and especially to lie on the large flat
indole rings of TRP side-chains (like this one does).

Gerard.

--
On Mon, Jul 02, 2018 at 04:01:29PM +0100, Eleanor Dodson wrote:
> Looks Pegy...
> 
> 
> On 2 July 2018 at 15:30, Artem Evdokimov  wrote:
> 
> > PEG snake or possibly a short, very disordered peptide (or several
> > peptides occupying the same density).
> >
> > Artem
> >
> > - Cosmic Cats approve of this message
> >
> > On Mon, Jul 2, 2018 at 6:26 AM, Christopher Horne  > canterbury.ac.nz> wrote:
> >
> >> Does anyone have any insight into this weird density?
> >>
> >> Present at dimer interface, PEG in condition. I have seen a previous post
> >> which mentions "PEGs can create ugly "snakes" of variable density that
> >> may be challenging to model".
> >>
> >>
> >>
> >> This email may be confidential and subject to legal privilege, it may
> >> not reflect the views of the University of Canterbury, and it is not
> >> guaranteed to be virus free. If you are not an intended recipient,
> >> please notify the sender immediately and erase all copies of the message
> >> and any attachments.
> >>
> >> Please refer to http://www.canterbury.ac.nz/its/email-disclaimer/  for more
> >> information.
> >>
> >>
> >> --
> >>
> >> 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
> >
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB=1



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

Re: [ccp4bb] Table 1 successor in 3D?

[Gerard Bricogne]

Dear John,

 Further to my reply below: Claus Flensburg pointed out to me that
there is an incorrect statement in your message:
 
> The anisotropy figure of Staraniso is indeed very useful and could
> complement Table 1, and clearly can only be made with unmerged data.

If you look at http://staraniso.globalphasing.org/staraniso_about.html
you will see that STARANISO can take unmerged intensity data as input
(points 1 to 10 in the list); however the program also accepts merged
intensity data (points 11 to 19), with best effect if no resolution
cut-off has yet been applied to them.

 Furthermore we have made available the PDBpeep server at 
 
 http://staraniso.globalphasing.org/cgi-bin/PDBpeep.cgi

that takes as input a 4-character PDB entry code and generates figures
from the deposited *merged amplitudes* aaociated with that entry. Your
statement therefore has no factual basis. The numbers coming out of a
PDBpeep run may well have questionable quantitative value (this is
pointed out in the home page for that server) but the informative
value of the 3D WebGL picture it produces has informative value
independently from that. Take a look, for instance, at 4zc9, 5f6m or
6c79: it is quite plain that these high-resolution datasets have
significant systematic incompleteness issues, a conclusion that would
not necessarily jump out of a Table 1 page.


 With best wishes,
 
  Gerard.

--
On Tue, Jun 05, 2018 at 02:02:53PM +0100, Gerard Bricogne wrote:
> Dear John,
> 
>  Thank you for your interesting comments. As far as the deposition
> of raw images is concerned, you are preaching to the converted in my
> case (I would even, if I may blow my own trumpet for a second, claim
> to have been one of the earliest proponents and most persistently
> vociferous defenders of the idea, long before it gained general
> acceptance). There has never been any statement on our part that the
> analysis done by STARANISO disposes of the need to store the original
> images and to revisit them regularly with improved processing and/or
> troubleshooting software, so I would be surprised if one could read
> such a message in what we have implemented and what Bernhard has
> written about. At any given stage in this evolution, however, the
> (re)processing results will need to be displayed, and it is with the
> matter of what information about data quality is conveyed (or not) by
> various modes of presentation of such results that Bernhard's argument
> and (part of) our work on STARANISO are concerned.
> 
>  Thank you also for the list of what STARANISO doesn't yet do, but
> be assured that most of these items already figure prominently on our
> long to-do list for the rapidly expanding set of functionalities of
> the program. My colleague Clemens Vonrhein likes to occasionally refer
> in our discussions to the universal wish for all-singing all-dancing
> software as the yearning for an "eierlegende Wollmilchsau", for which
> I am told that an approximate English transation would be "egg-laying
> Wool-Milk-Pig". It is on its way, but it will take a bit longer ;-) ,
> one step at a time.
> 
> 
>  With best wishes,
>  
>   Gerard.
> 
> --
> On Tue, Jun 05, 2018 at 11:09:42AM +0100, John R Helliwell wrote:
> > Dear Colleagues
> > Thankyou to Gerard for the prompt of last Friday on CCP4bb to read in
> > detail Bernhard's perspective in Structure on “Table 1”.
> > 
> > The anisotropy figure of Staraniso is indeed very useful and could
> > complement Table 1, and clearly can only be made with unmerged data.
> > 
> > However, the Perspective does not address some of the problems that
> > could exist with the data that are not evident from a Table I
> > 
> > summary, nor from the Staraniso figures, as they are the result of
> > data processing. Some aspects of reciprocal space could have been
> > 
> > completely missed or ignored: pseudo-merohedral twinning or multiple
> > lattices, incommensurate modulation and diffuse streaks.
> > 
> > These can be visualized by reciprocal space reconstructions from the
> > detector images, such as available in EVAL.
> > 
> > Furthermore without these special features in the raw diffraction
> > image*s* the raw data allow for reprocessing by readers of
> > 
> > article*s* by their preferred software as well as at different
> > resolutions to evaluate optimal model quality (aka Deiderichs and
> > 
> > Karplus). Overall this means that we can work towards methods that
> > provide us with quality indicators for how well the data
> > 
> > processing step actually explains the diffraction patterns in detector
> > or reciprocal space.
> > 
> &

Re: [ccp4bb] Table 1 successor in 3D?

[Gerard Bricogne]

Dear John,

 Thank you for your interesting comments. As far as the deposition
of raw images is concerned, you are preaching to the converted in my
case (I would even, if I may blow my own trumpet for a second, claim
to have been one of the earliest proponents and most persistently
vociferous defenders of the idea, long before it gained general
acceptance). There has never been any statement on our part that the
analysis done by STARANISO disposes of the need to store the original
images and to revisit them regularly with improved processing and/or
troubleshooting software, so I would be surprised if one could read
such a message in what we have implemented and what Bernhard has
written about. At any given stage in this evolution, however, the
(re)processing results will need to be displayed, and it is with the
matter of what information about data quality is conveyed (or not) by
various modes of presentation of such results that Bernhard's argument
and (part of) our work on STARANISO are concerned.

 Thank you also for the list of what STARANISO doesn't yet do, but
be assured that most of these items already figure prominently on our
long to-do list for the rapidly expanding set of functionalities of
the program. My colleague Clemens Vonrhein likes to occasionally refer
in our discussions to the universal wish for all-singing all-dancing
software as the yearning for an "eierlegende Wollmilchsau", for which
I am told that an approximate English transation would be "egg-laying
Wool-Milk-Pig". It is on its way, but it will take a bit longer ;-) ,
one step at a time.


 With best wishes,
 
  Gerard.

--
On Tue, Jun 05, 2018 at 11:09:42AM +0100, John R Helliwell wrote:
> Dear Colleagues
> Thankyou to Gerard for the prompt of last Friday on CCP4bb to read in
> detail Bernhard's perspective in Structure on “Table 1”.
> 
> The anisotropy figure of Staraniso is indeed very useful and could
> complement Table 1, and clearly can only be made with unmerged data.
> 
> However, the Perspective does not address some of the problems that
> could exist with the data that are not evident from a Table I
> 
> summary, nor from the Staraniso figures, as they are the result of
> data processing. Some aspects of reciprocal space could have been
> 
> completely missed or ignored: pseudo-merohedral twinning or multiple
> lattices, incommensurate modulation and diffuse streaks.
> 
> These can be visualized by reciprocal space reconstructions from the
> detector images, such as available in EVAL.
> 
> Furthermore without these special features in the raw diffraction
> image*s* the raw data allow for reprocessing by readers of
> 
> article*s* by their preferred software as well as at different
> resolutions to evaluate optimal model quality (aka Deiderichs and
> 
> Karplus). Overall this means that we can work towards methods that
> provide us with quality indicators for how well the data
> 
> processing step actually explains the diffraction patterns in detector
> or reciprocal space.
> 
> Therefore, we reiterate that raw diffraction data should be stored and
> the dois cited in publications and the PDB depositions.
> 
> 
> 
> Best wishes,
> Loes and John
> See Kroon Batenburg et al 2017 IUCrJ and Helliwell et al IUCrJ 2017.
> 
> 
> 
> On Mon, Jun 4, 2018 at 10:39 AM, Bernhard Rupp  wrote:
> 
> > The point is that **once you have a 3D representation of the RL**, you
> >
> > can map whatever RS metric you like on that presentation and articulate
> >
> > its effect on real space. In case of resolution measures this is straight
> > forward;
> >
> > where it becomes interesting is at other atrocities and mutilations of the
> >
> > data, some of which Gerard has already mentioned.
> >
> >
> >
> > Ultimately, once you have classified and ranked the defects of data
> >
> > collection, you can look for them proactively and take corrective measures
> >
> > already in the data collection process. To some degree the automated
> >
> > collection and processing programs do that (e.g. exposure) but there are
> >
> > significant deficiencies that are stated posterior but not addressed in
> > the process
> >
> > (e.g. optimal detector positions, orientations).
> >
> >
> >
> > Best, BR
> >
> >
> >
> > *From:* Alexandre Ourjoumtsev 
> > *Sent:* Monday, June 4, 2018 10:07
> > *To:* Gerard Bricogne ; bernhard.r...@i-med.ac.at
> > *Cc:* CCP4BB@JISCMAIL.AC.UK
> > *Subject:* Re: [ccp4bb] Table 1 successor in 3D?
> >
> >
> >
> > Dear Bernhard and Gerard,
> >
> >
> >
> > congratulations for nice results that both y

Re: [ccp4bb] A new capability on the STARANISO server: "PDBpeep"

[Gerard Bricogne]

Dear Jeffrey,

 Thank you for sharing your observations and the questions they
bring up.

 I can see two things in the 3D displays for your two PDB entries,
none of which seems new or surprising.

 The first is that there is a peppering of blue dots within the
volume that otherwise seems occupied with colours indicating the
presence of significant data. This can be created by the rejection of
individual misfits, or by the folding over by symmetry of detector
gaps (see 5lgk for a spectacular example of the latter!).

 The second is indeed a waviness of the boundary surfaces between
different colours. This is because the local average of I/sig(I) is
modulated by the distribution of I itself (if there were only Poisson
statistics errors entering sig(I), then each I/sig(I) would just be
sqrt(I)), and also by the multiplicity of measurement through the
1/sqrt(multiplicity) factor. When you combine those two distinct and
independent influences, you can get quite a lot of directional
modulation in the local average of of I/sig(I), the first kind coming
largely from the tertiary structure of the molecule and the second
from the way the data were collected.

 These simple things are easily forgotten if there isn't direct
visual evidence for their existence.

 Thank you again: this feedback is very useful in pointing out
what needs commenting upon to makes these plots understandable.


 With best wishes,
 
  Gerard.

--
On Wed, Mar 28, 2018 at 08:22:23PM +, Jeffrey B Bonanno wrote:
> Hi Gerard,
> 
> Very nice server indeed. I reviewed the 3D plots of some recent high res 
> structures and am struck by the granularity which is not necessarily globally 
> directional. For instance, I ran 4QRN and 5EHI and see "ripples" in the 
> I/sigI plot between the various "layers" (higher res yellow to orange 
> "transition" features are most easily visible but the purple to blue low res 
> are very interesting as well). Can you comment on the significance of these 
> intensity-weighted reciprocal lattice features as pertains to real space? It 
> is tempting to see a manifestation of the solvent mask in the color coding :-)
> 
> best,
> Jeff
> 
> 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...@einstein.yu.edu
> 
> -Original Message-
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Gerard 
> Bricogne
> Sent: Wednesday, March 28, 2018 2:35 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] A new capability on the STARANISO server: "PDBpeep"
> 
> Dear Jacob,
> 
>  Thank you for the appreciative comment.
>  
>  I am not sure that there is any such thing as an up-to-date
> estimate of the prevalence of anisotropy in the PDB - but now you can
> get a feel for it yourself by looking at any entries you want. However
> please do not submit the whole PDB to the server - yet ;-) .
> 
>  From looking at anisotropy as visible through the overall scaling
> Debye-Waller factor, I would say that whenever anisotropy is allowed
> by the Laue group, it will be present, even if mild. Symmetry lower
> than cubic means that intermolecular contacts along directions that
> are not symmetry-equivalent will be different, and there is no reason
> why different contacts should create identical degrees of long-range
> order.
> 
> 
>  Have fun!
>  
>   Gerard.
> 
> --
> On Wed, Mar 28, 2018 at 06:13:29PM +, Keller, Jacob wrote:
> > Wow, this is really cool--just tried a quick look at a recent membrane 
> > protein (5eqi) and you can see right away that there is anisotropy.
> > 
> > I would guess this can be found in the literature, but how prevalent is 
> > anisotropy in the PDB?
> > 
> > Jacob Keller
> > 
> > +
> > Jacob Pearson Keller
> > Research Scientist / Looger Lab
> > HHMI Janelia Research Campus
> > 19700 Helix Dr, Ashburn, VA 20147
> > Desk: (571)209-4000 x3159
> > Cell: (301)592-7004
> > +
> > 
> > The content of this email is confidential and intended for the recipient 
> > specified in message only. It is strictly forbidden to share any part of 
> > this message with any third party, without a written consent of the sender. 
> > If you received this message by mistake, please reply to this message and 
> > follow with its deletion, so that we can ensure such a mistake does not 
> > occur in the future.
> > 
> > -Original Message-
> > 

Re: [ccp4bb] A new capability on the STARANISO server: "PDBpeep"

[Gerard Bricogne]

Dear Jacob,

 Thank you for the appreciative comment.
 
 I am not sure that there is any such thing as an up-to-date
estimate of the prevalence of anisotropy in the PDB - but now you can
get a feel for it yourself by looking at any entries you want. However
please do not submit the whole PDB to the server - yet ;-) .

 From looking at anisotropy as visible through the overall scaling
Debye-Waller factor, I would say that whenever anisotropy is allowed
by the Laue group, it will be present, even if mild. Symmetry lower
than cubic means that intermolecular contacts along directions that
are not symmetry-equivalent will be different, and there is no reason
why different contacts should create identical degrees of long-range
order.


 Have fun!
 
  Gerard.

--
On Wed, Mar 28, 2018 at 06:13:29PM +, Keller, Jacob wrote:
> Wow, this is really cool--just tried a quick look at a recent membrane 
> protein (5eqi) and you can see right away that there is anisotropy.
> 
> I would guess this can be found in the literature, but how prevalent is 
> anisotropy in the PDB?
> 
> Jacob Keller
> 
> +
> Jacob Pearson Keller
> Research Scientist / Looger Lab
> HHMI Janelia Research Campus
> 19700 Helix Dr, Ashburn, VA 20147
> Desk: (571)209-4000 x3159
> Cell: (301)592-7004
> +
> 
> The content of this email is confidential and intended for the recipient 
> specified in message only. It is strictly forbidden to share any part of this 
> message with any third party, without a written consent of the sender. If you 
> received this message by mistake, please reply to this message and follow 
> with its deletion, so that we can ensure such a mistake does not occur in the 
> future.
> 
> -Original Message-----
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Gerard 
> Bricogne
> Sent: Wednesday, March 28, 2018 11:56 AM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] A new capability on the STARANISO server: "PDBpeep"
> 
> Dear all,
> 
>  Ever since the WebGL viewer became available on the STARANISO server, we 
> have found ourselves using it with increasing frequency to take a quick look 
> (a "peep") at the diffraction data deposited with various PDB entries - for 
> example, to try and identify a root cause for some sub-optimal refinement 
> results, or, quite often, just out of sheer curiosity!
> 
>  This involved a totally straightforward procedure whereby the 
> diffraction data file associated with a given PDB entry was downloaded from 
> the PDB and subsequently uploaded to the STARANISO server.
> 
>  Gradually, however, this operation became so popular among some of us 
> that we thought it would be useful to implement this simple procedure as an 
> autonomous capability - and thus was born "PDBpeep" !
> 
>  You can access this new feature by connecting to 
> 
>http://staraniso.globalphasing.org/cgi-bin/PDBpeep.cgi 
> 
> and enter a PDB code into the box. As indicated on that page, this provides 
> only a cursory look at the overall quality of each dataset, and any further 
> analysis or output can only be obtained by submitting the datafile to the 
> STARANISO server. Better results would clearly be obtainable if the raw 
> images for these datasets had been deposited and could be reprocessed, with 
> the untruncated output of that processing then being submitted to the 
> STARANISO server (reprocessing the images with autoPROC would combine those 
> two steps into a single one).
> 
>  Most of the deposited datasets have been isotropically truncated, and 
> their 3D view in WebGL often suggests that this truncation was too drastic. A 
> number of entries will show infelicities - such as cusps and/or missing 
> angular ranges, or even stripes caused by gaps between the modules of pixel 
> detectors if the beam centre is at a position symmetric relative to those 
> gaps - all marked up in blue.
> 
> 
>  Our purpose in sharing this capability with the community is to bring a 
> further contribution to the process of making everyone more "data quality 
> aware" and keen to scrutinise more closely the protocols by which they 
> collect diffraction data, or have such data collected on their behalf.
> 
> 
>  We will be grateful to receive feedback about PDBpeep, just as we have 
> been about the STARANISO server itself.
> 
> 
>  With best wishes,
> 
>  The STARANISO developers.

-- 

 ===
 * *
 * Gerard Bricogn

[ccp4bb] A new capability on the STARANISO server: "PDBpeep"

[Gerard Bricogne]

Dear all,

 Ever since the WebGL viewer became available on the STARANISO
server, we have found ourselves using it with increasing frequency to
take a quick look (a "peep") at the diffraction data deposited with
various PDB entries - for example, to try and identify a root cause
for some sub-optimal refinement results, or, quite often, just out of
sheer curiosity!

 This involved a totally straightforward procedure whereby the
diffraction data file associated with a given PDB entry was downloaded
from the PDB and subsequently uploaded to the STARANISO server.

 Gradually, however, this operation became so popular among some
of us that we thought it would be useful to implement this simple
procedure as an autonomous capability - and thus was born "PDBpeep" !

 You can access this new feature by connecting to 

   http://staraniso.globalphasing.org/cgi-bin/PDBpeep.cgi 

and enter a PDB code into the box. As indicated on that page, this
provides only a cursory look at the overall quality of each dataset,
and any further analysis or output can only be obtained by submitting
the datafile to the STARANISO server. Better results would clearly be
obtainable if the raw images for these datasets had been deposited and
could be reprocessed, with the untruncated output of that processing
then being submitted to the STARANISO server (reprocessing the images
with autoPROC would combine those two steps into a single one).

 Most of the deposited datasets have been isotropically truncated,
and their 3D view in WebGL often suggests that this truncation was too
drastic. A number of entries will show infelicities - such as cusps
and/or missing angular ranges, or even stripes caused by gaps between
the modules of pixel detectors if the beam centre is at a position
symmetric relative to those gaps - all marked up in blue.


 Our purpose in sharing this capability with the community is to
bring a further contribution to the process of making everyone more
"data quality aware" and keen to scrutinise more closely the protocols
by which they collect diffraction data, or have such data collected on
their behalf.


 We will be grateful to receive feedback about PDBpeep, just as we
have been about the STARANISO server itself.


 With best wishes,

 The STARANISO developers.

Re: [ccp4bb] Reference for hanging drop crystallization

[Gerard Bricogne]

ce, in most
> cases, a high-resolution crystal structure (< 2.0 Å)will provide a better
> description of the structure in solution than the corresponding NMR
> structure  (Kuszewski, Gronenborn & Clore, 1996, Protein Science 5:1067-80)
> --
> Disclaimer
> * This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and delete
> this e-mail from your system.
> * E-mail transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive late or
> incomplete, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message, which
> arise as a result of e-mail transmission. If verification is required please
> request a hard-copy version. Please send us by fax any message containing
> deadlines as incoming e-mails are not screened for response deadlines.
> * Employees of the Institute are expressly required not to make defamatory
> statements and not to infringe or authorize any infringement of copyright or
> any other legal right by email communications. Any such communication is
> contrary to Institute policy and outside the scope of the employment of the
> individual concerned. The Institute will not accept any liability in respect
> of such communication, and the employee responsible will be personally
> liable for any damages or other liability arising. Employees who receive
> such an email must notify their supervisor immediately.
> --
> 

-- 

 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===

Re: [ccp4bb] Anisotropic Scaling

[Gerard Bricogne]

Dear Liang,

 In this case I cannot refrain from mentioning the STARANISO
server at

 http://staraniso.globalphasing.org/

It offers a certain amount of background explanations, with a didactic
aim, that hopefully will help you understand what it does and what its
results provide you with.

 If you like what it does, then you can get all the benefits from
it by letting autoPROC (https://www.globalphasing.com/autoproc/) run
it for you as part of the processing of your raw images.

 Good luck!
 
 
 With best wishes,
 
  Gerard.

--
On Sat, Jan 13, 2018 at 02:52:46PM -0500, Jacqueline Vitali wrote:
> There is an anisotropy server from ucla that I think you can use over the
> internet,  Just google it and try it to see if it helps with your data.  I
> think the data is better afterwards,
> 
> Jackie Vitali
> Cleveland State University
> 
> On Sat, Jan 13, 2018 at 5:53 AM, Zhang Foggy  wrote:
> 
> > Dear Crystallographers,
> >
> > Sorry for the non-ccp4 topic.
> >
> > Recently I collected a set of diffraction data with significant diffraction
> > anisotropy (two directions to 3.0A, while the other to 3.7A). The overall
> > resolution can only be scaled to 3.3A (I/sigma=1.04). I have read some
> > publications that they can scale the data under different directions rather
> > than overall by using HKL3000 (like the table in attached figure), which
> > can describe the anisotropy more accurate. Does anyone can tell me how to
> > scale the data like that?
> >
> > Thank you in advance.
> >
> > Best,
> >
> > Liang
> >

Re: [ccp4bb] new ContaMiner features

[Gerard Bricogne]

Dear Stefan,

 Thank you for your message. I am sure that we will figure out
what caused the spurious results described by Pierre, now that we know
about them ;-) . 

 Perhaps my reaction to your message was a little too loaded with
tension, and if so I regret it. The fact is that we are encountering
much "mental viscosity" in our discussions about a simple framework
for anisotropic statistics, which makes it hard not to become a bit 
defensive at times. 

 It was nice to read that your ContaMiner server is so highly
appreciated!


 With best wishes,
 
  Gerard.

--
On Fri, Nov 24, 2017 at 03:12:50PM +0100, Stefan Arold wrote:
> Dear Gerard
> 
> I am really sorry that my badly formulated 'final word of warning' has made
> you and others spend much time for composing well-formulated replies. I was
> at PX1 yesterday, and Leo reminded me of the issue, hence I included it
> into my message.
> You are absolutely right that reports of anomalies should go to the
> developers - however the issue here is already known (as shown in the
> STARANISO Warning message) and cannot be solved by us at the ContaMiner
> level. Given the popularity of Staraniso, I just wanted to inform our users
> that this particular issue is propagated into the ContaMiner results. I
> should have worded it more carefully.
> 
> Many thanks to Leo and Pierre for helping explain!
> 
> With best wishes
> Stefan
> 
> 
> 
> On 24 November 2017 at 13:07, Gerard Bricogne <g...@globalphasing.com>
> wrote:
> 
> > Dear Radu,
> >
> >  I would not want to take undue advantage of this already
> > voluminous thread, but your PS takes us into a different direction,
> > namely the whole myth-ridden topic of "weak data" - but that will be
> > for another thread, another time ;-) .
> >
> >
> >  With best wishes,
> >
> >   Gerard.
> >
> > --
> > On Fri, Nov 24, 2017 at 01:02:08AM -, r...@mrc-lmb.cam.ac.uk wrote:
> > > Hi Leo,
> > >
> > > I agree that the horror beamline stories you describe are far too common.
> > > Unfortunately, they start earlier, in the wet lab or even before.
> > Exactly the
> > > same attitude (careless construct design, crystallising whatever "dirty"
> > > samples, not bothering optimising cryoprotection and so on) leads to
> > wasting a
> > > lot of resources, including synchrotron time. In some cases, as people
> > pointed
> > > out, problems such as contaminations (and even more so anisotropic data,
> > for
> > > the matter) are unavoidable. But too often, as we all know, it's simply
> > bad
> > > practice, lack of training etc. Web servers can only help up to a
> > point...
> > >
> > > Best wishes,
> > >
> > > Radu
> > > PS: At least, one day, maximum-likelihood refinement programs will deal
> > with
> > > weak data satisfactorily :-) Nobody likes to throw data away.
> > >
> > >
> > > > Dear all,
> > > >
> > > > to join Pierre's comments on what 'strange' things happen at the
> > beamlines...
> > > > yet not too strange for (too) many people: huge screening of salt
> > crystals,
> > > > complete data collection of dramatically low resolution data, full
> > power
> > > > coupled with 360Deg data collection etc. etc. etc. We do unfortunately
> > see too
> > > > many 'blind shots, deal with it later, and move on' experiments that it
> > > > becomes depressive. I personally do not see why we would close our
> > eyes to
> > > > servers and/or data analysis tools that could help you think less, or
> > better
> > > > say help you understanding what is eventually happening with your data.
> > > >
> > > > Cheers, leo
> > > >
> > > > -
> > > > Leonard Chavas
> > > > -
> > > > Synchrotron SOLEIL
> > > > Proxima-I
> > > > L'Orme des Merisiers
> > > > Saint-Aubin - BP 48
> > > > 91192 Gif-sur-Yvette Cedex
> > > > France
> > > > -
> > > > Phone:  +33 169 359 746
> > > > Mobile: +33 644 321 614
> > > > E-mail: leonard.cha...@synchrotron-soleil.fr
> > > > -
> > > >
> > > >> On 24 Nov 2017, at 00:23, Edward A. Berry <ber...@upstate.edu> wrote:
> > > >>
> > > >> My 2 cents worth:
> > > >> I think contaminer is an extremely useful service. I may be a sloppy
> > > >> 

Re: [ccp4bb] new ContaMiner features

[Gerard Bricogne]

arding your final paragraph: your server carries a warning
> >>>>> with the exact wording:
> >>>>>
> >>>>>"Submitting StarAniso files can give you suspicious results. Use
> >>>>> with care!"
> >>>>>
> >>>>>It seems rather regrettable that you are posting such a public
> >>>>> warning without ever having contacted the STARANISO developers about
> >>>>> your observations, nor giving any information about what you call
> >>>>> "suspicious" or what the "care" you recommend would consist of.
> >>>>>
> >>>>>We have taken a great deal of care ourselves in developing the
> >>>>> program and offering it to the community through a server, and the
> >>>>> least we would have expected is that any pattern of "suspicious"
> >>>>> results would be referred to us so that we could investigate them.
> >>>>> There may be some assumptions made in MoRDa that we are not aware of,
> >>>>> that might be incompatible with assumptions made in STARANISO - who
> >>>>> knows? Or it could be that some particularly badly collected datasets
> >>>>> are made to look worse after their anisotropy analysis.
> >>>>>
> >>>>>Could we discuss your observations, and what it is exactly that
> >>>>> you call "suspicious", before they end up being referred to in such an
> >>>>> uninformative manner as some sort of "Government Health Warning"?
> >>>>>
> >>>>>I think that would be nice :-) and we would be only too keen to
> >>>>> take whatever extra "care" is needed ourselves. We would all learn
> >>>>> something.
> >>>>>
> >>>>>
> >>>>>With best wishes,
> >>>>>
> >>>>> Gerard.
> >>>>>
> >>>>> (on behalf of the STARANISO developers)
> >>>>>
> >>>>> --
> >>>>> On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
> >>>>>> Dear Community,
> >>>>>>
> >>>>>> A quick message to announce the following two new features on our
> >>>>>> ContaMiner web server for the automated detection of unwantedly
> >>>>>> crystallised contaminants (
> >>>>>> https://strube.cbrc.kaust.edu.sa/contaminer/submit)
> >>>>>>
> >>>>>> 1) online visualisation of 2FoFc and FoFc maps. In cases of positive
> >>>>>> results, the ???UglyMol??? tab allows to inspect 2FoFc and FoFc maps
> >>>>>> directly
> >>>>>> in the web browser. Thi
> >>>>>>
> >>>>>> 2) life-update. Previously, results were sent to you once all ~2000 MR
> >>>>>> jobs
> >>>>>> were finished. Now, the individual results for each potential
> >>>>>> contaminant
> >>>>>> will appear as soon as they are finished. This feature should
> >>>>>> substantially
> >>>>>> shorten the time for identifying positive results (i.e. contaminant
> >>>>>> detected), which are terminated faster than negative ones.
> >>>>>>
> >>>>>> 3) custom contaminants. In the ???Advanced??? tab, users can upload own
> >>>>>> PDB
> >>>>>> files (more than one is possible) to be included as search models. This
> >>>>>> feature can be used to include PDB files from your lab bench
> >>>>>> neighbour???s
> >>>>>> project to test for potential lab internal contaminations (through
> >>>>>> bacterial contamination or through mix-up of plasmids or glycerol
> >>>>>> stocks).
> >>>>>> This feature could also be ???abused??? as a means to use the MoRDa
> >>>>>> pipeline
> >>>>>> to
> >>>>>> run molecular replacements with template structures that are not yet
> >>>>>> deposited in the PDB; for example to run molecular replacement and
> >>>>>> initial
> >>>>>> refinement for liganded or complexed versions of an unpublished
> >>>>>> structure.
> >>>>>> This might be particularly interesting for crystallographers away from
> >>>>>> their usual home software environment (e.g. at the beamline).
> >>>>>>
> >>>>>> Finally, a word of warning ??? Staraniso files might give false
> >>>>>> positives if
> >>>>>> they have large anisotropic cuts.
> >>>>>>
> >>>>>> Keep your crystals clean!
> >>>>>>
> >>>>>> With best wishes
> >>>>>>
> >>>>>> The ContaMiner Team
> >>>>>
> >>>>> --
> >>>>>
> >>>>>===
> >>>>>* *
> >>>>>* Gerard Bricogne g...@globalphasing.com
> >>>>> <mailto:g...@globalphasing.com>  *
> >>>>>* *
> >>>>>* Global Phasing Ltd. *
> >>>>>* Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
> >>>>>* Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
> >>>>>* *
> >>>>>===
> >>>>>
> >
> >
> 
> 
> -- 
> Radu Aricescu
> MRC Laboratory of Molecular Biology
> Francis Crick Avenue
> Cambridge Biomedical Campus
> Cambridge CB2 0QH, U.K.
> tel: +44-(0)1223-267049
> fax: +44-(0)1223-268305
> www: http://www2.mrc-lmb.cam.ac.uk/group-leaders/a-to-g/radu-aricescu

Re: [ccp4bb] new ContaMiner features

[Gerard Bricogne]

Dear Leo,

 Thank you for your message. I would hurry to say that there is no
notion of blame in this whole situation - if there were any, then I
would blame myself for being perhaps too abrupt and severe-sounding in
my message of yesterday :-) .

 Returning to the main issue, it would certainly be our preferred
option if any anomalies spotted in the results of STARANISO, or in the
behaviour of programs using these results, could be reported to us
first. It isn't a matter of wanting to avoid open discussions and
scrutiny, but this is a program under very active development and most
problems will be bugs, so that reporting them publicly would flood
CCP4BBers' mailboxes with spam and the BB itself with a lot of
ephemeral noise. We have a specific e-mail address for such reports,
given on the server.

 Being in charge of a top-notch beamline associated with beamline
scientists like Pierre who have a keen interest in data analysis, you
are in a perfect position to help us improve the program. As you have
noted, it not only does some number crunching, but it offers a 3D
interactive overview of the quality of datasets that is quite novel
and is meant to contribute (we are not the only ones!) to encouraging
users to think in terms of quality again and not just of getting a few
numbers that won't raise reviewers' eyebrows when placed into some
sensitive cells of Table 1.

 Let us look forward to some fruitful exchanges of data and
results, then!


 With best wishes,
 
  Gerard.

--
On Fri, Nov 24, 2017 at 12:07:26AM +, CHAVAS Leonard wrote:
> Dear Gerard
> 
> I should certainly be the one to blame, as I was the one spotting this 
> behaviour to Stefan. Telling this, it could indeed be a problem with the data 
> set, yet submitting the original mtz to ContaMiner provided with the 
> strangely hoped and expected ContaMiner negative result. I made few tests 
> afterwards, quick ones, with other mtz files treated or not with Staraniso, 
> and although the direct results were not exactly the same as the extreme 'all 
> positive' results noted earlier, it behaved strange (all 'possible positive', 
> while standard non-contaminant data give you all 'negative' results).
> 
> I then ran MorDa standalone and found the same behaviour: for the first 
> trial, it did found a solution... while there were none. Interestingly, 
> Rfac/Rfree in the resulting MorDa solved structure was something like 
> 50/20... I strongly believe that MorDa, and hence ContaMiner, scores its 
> results on the Rfree value. Errors could have been spotted by looking at the 
> ratio, which clearly was showing that something wrong is happening, operation 
> either on MorDa or on ContaMiner side (or even both). 
> 
> Additional investigations are obviously welcome, however and for now, I guess 
> the message from Stefan was more in the idea to warn people that having too 
> many positive hits for one single data probably means something is wrong with 
> the ContaMiner/MorDa processing, more than something is wrong with the 
> dataset itself. That goes without saying that something could go wrong if the 
> dataset is wrong, obviously... 
> 
> To Gerard and good willing developers: would you need the badly behaving 
> data, please do let me know and I shall send it to you offline.
> 
> Cheers, leo
> 
> -
> Leonard Chavas
> - 
> Synchrotron SOLEIL
> Proxima-I
> L'Orme des Merisiers
> Saint-Aubin - BP 48
> 91192 Gif-sur-Yvette Cedex
> France
> - 
> Phone:  +33 169 359 746
> Mobile: +33 644 321 614
> E-mail: leonard.cha...@synchrotron-soleil.fr
> -
> 
> > On 23 Nov 2017, at 23:53, Gerard Bricogne <g...@globalphasing.com> wrote:
> > 
> > Dear Pierre,
> > 
> > Thank you for throwing some light on the circumstances under
> > which the "suspicious" results cropped up :-) . Was the "Government
> > Heatlh Warning" based on this one and only mtz file, then?
> > 
> > We would certainly be interested in examining this dataset for
> > any anomalies in the anisotropy analysis and the mtz file it produced
> > (perhaps you can simply give us the job ID on the server). However the
> > "results" consist of the spurious recognition of molecules that are
> > known not to be in the crystal, so they are the outcome of numerous
> > unspecified steps downstream of the anisotropy analysis itself, that
> > in the end produce a "score" that is misleading. It would be useful to
> > have at least some idea of what those steps are in order to identify
> > the possible causes of the erroneous detections. 
> > 
> > 
> > With best wishes,
> > 
> >  Gerard.
> > 
> > --
> > On Thu, Nov 23, 2017 at 10:05:0

Re: [ccp4bb] new ContaMiner features

[Gerard Bricogne]

Dear Pierre,

 Thank you for throwing some light on the circumstances under
which the "suspicious" results cropped up :-) . Was the "Government
Heatlh Warning" based on this one and only mtz file, then?

 We would certainly be interested in examining this dataset for
any anomalies in the anisotropy analysis and the mtz file it produced
(perhaps you can simply give us the job ID on the server). However the
"results" consist of the spurious recognition of molecules that are
known not to be in the crystal, so they are the outcome of numerous
unspecified steps downstream of the anisotropy analysis itself, that
in the end produce a "score" that is misleading. It would be useful to
have at least some idea of what those steps are in order to identify
the possible causes of the erroneous detections. 


 With best wishes,
 
  Gerard.

--
On Thu, Nov 23, 2017 at 10:05:09PM +, LEGRAND Pierre wrote:
> Dear Gérard,
> 
> As being part of the group how has initially raised the issue to Stefan, I 
> stand out to try clarifying a misinterpretation.
> In brief, because we are happy users of StarAniso, it happened that we have 
> submitted an mtz that it had produced to the ContaMiner server. We were very 
> surprised to find that almost all contaminants evaluated gave high scores 
> according to MoRDa. On the contrary, using an "isotropicaly" treated mtz, no 
> hit could be detected in by ContaMiner.
> 
> Being collected on PROXIMA-1 beamline, it coun't be a "badly collected 
> datasets" ;-)
> 
> So, most probably, as you suggested, the issue is linked to some bad 
> assumptions made by MoRDa or inadequate criteria choices _in_the_cases_ of 
> "corrected" anisotropic data. 
> We can probably provide some examples of datasets to the developers willing 
> to pursue investigations on this.
> 
> I completely agree with Tristan! I have to admit having lost several weeks in 
> my career (if not months) with "contaminated" crystals. And working on an MX 
> beamline, I can testify that this is unfortunately happening regularly. 
> 
> I will finish with a big thanks to all the (StarAniso/ContaMiner/MoRDA) 
> developers how are helping us to untwist the unavoidable experimental 
> mess/reality.
> 
> Kind regards,
> Pierre 
> 
> De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Gerard 
> Bricogne [g...@globalphasing.com]
> Envoyé : jeudi 23 novembre 2017 19:34
> À : CCP4BB@JISCMAIL.AC.UK
> Objet : Re: [ccp4bb] new ContaMiner features
> 
> Dear Stefan,
> 
>  Regarding your final paragraph: your server carries a warning
> with the exact wording:
> 
>  "Submitting StarAniso files can give you suspicious results. Use
> with care!"
> 
>  It seems rather regrettable that you are posting such a public
> warning without ever having contacted the STARANISO developers about
> your observations, nor giving any information about what you call
> "suspicious" or what the "care" you recommend would consist of.
> 
>  We have taken a great deal of care ourselves in developing the
> program and offering it to the community through a server, and the
> least we would have expected is that any pattern of "suspicious"
> results would be referred to us so that we could investigate them.
> There may be some assumptions made in MoRDa that we are not aware of,
> that might be incompatible with assumptions made in STARANISO - who
> knows? Or it could be that some particularly badly collected datasets
> are made to look worse after their anisotropy analysis.
> 
>  Could we discuss your observations, and what it is exactly that
> you call "suspicious", before they end up being referred to in such an
> uninformative manner as some sort of "Government Health Warning"?
> 
>  I think that would be nice :-) and we would be only too keen to
> take whatever extra "care" is needed ourselves. We would all learn
> something.
> 
> 
>  With best wishes,
> 
>   Gerard.
> 
> (on behalf of the STARANISO developers)
> 
> --
> On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
> > Dear Community,
> >
> > A quick message to announce the following two new features on our
> > ContaMiner web server for the automated detection of unwantedly
> > crystallised contaminants (
> > https://strube.cbrc.kaust.edu.sa/contaminer/submit)
> >
> > 1) online visualisation of 2FoFc and FoFc maps. In cases of positive
> > results, the ‘UglyMol’ tab allows to inspect 2FoFc and FoFc maps directly
> > in the web browser. Thi
> >
> > 2

Re: [ccp4bb] new ContaMiner features

[Gerard Bricogne]

Dear Stefan,

 Regarding your final paragraph: your server carries a warning
with the exact wording:

 "Submitting StarAniso files can give you suspicious results. Use
with care!"

 It seems rather regrettable that you are posting such a public
warning without ever having contacted the STARANISO developers about
your observations, nor giving any information about what you call
"suspicious" or what the "care" you recommend would consist of. 

 We have taken a great deal of care ourselves in developing the
program and offering it to the community through a server, and the
least we would have expected is that any pattern of "suspicious"
results would be referred to us so that we could investigate them.
There may be some assumptions made in MoRDa that we are not aware of,
that might be incompatible with assumptions made in STARANISO - who
knows? Or it could be that some particularly badly collected datasets
are made to look worse after their anisotropy analysis. 

 Could we discuss your observations, and what it is exactly that
you call "suspicious", before they end up being referred to in such an
uninformative manner as some sort of "Government Health Warning"?

 I think that would be nice :-) and we would be only too keen to
take whatever extra "care" is needed ourselves. We would all learn
something.
 
 
 With best wishes,
 
  Gerard.

(on behalf of the STARANISO developers)

--
On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
> Dear Community,
> 
> A quick message to announce the following two new features on our
> ContaMiner web server for the automated detection of unwantedly
> crystallised contaminants (
> https://strube.cbrc.kaust.edu.sa/contaminer/submit)
> 
> 1) online visualisation of 2FoFc and FoFc maps. In cases of positive
> results, the ‘UglyMol’ tab allows to inspect 2FoFc and FoFc maps directly
> in the web browser. Thi
> 
> 2) life-update. Previously, results were sent to you once all ~2000 MR jobs
> were finished. Now, the individual results for each potential contaminant
> will appear as soon as they are finished. This feature should substantially
> shorten the time for identifying positive results (i.e. contaminant
> detected), which are terminated faster than negative ones.
> 
> 3) custom contaminants. In the ‘Advanced’ tab, users can upload own PDB
> files (more than one is possible) to be included as search models. This
> feature can be used to include PDB files from your lab bench neighbour’s
> project to test for potential lab internal contaminations (through
> bacterial contamination or through mix-up of plasmids or glycerol stocks).
> This feature could also be ‘abused’ as a means to use the MoRDa pipeline to
> run molecular replacements with template structures that are not yet
> deposited in the PDB; for example to run molecular replacement and initial
> refinement for liganded or complexed versions of an unpublished structure.
> This might be particularly interesting for crystallographers away from
> their usual home software environment (e.g. at the beamline).
> 
> Finally, a word of warning – Staraniso files might give false positives if
> they have large anisotropic cuts.
> 
> Keep your crystals clean!
> 
> With best wishes
> 
> The ContaMiner Team

-- 

 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===

Re: [ccp4bb] reject images based on Rmerge

[Gerard Bricogne]

Dear Charles,

 Eleanor is right: look at the images, and look also at the
processing output produced by XDS. If you find that too ASCII-looking,
then look at the graphs produced from these numbers by programs like
XDSGUI, XDSAPP and others. Our own autoPROC produces an extensive html
output (called "summary.html") that will contain all these graphs.

 In general you have to look at several of them simultanously to
figure out what went wrong. Your type of problem is often produced by
a bad crystal centring that causes the crystal to move out of the beam
in some ranges of images. In that case you can see that the number of
indexed spots as a function of image number goes down to worryingly
low values in certain ranges, and that the image scale factors and
B-factor have large excursions for those same ranges, that are also
the ranges where the Rmerge values end up quite high. In this case it
is just because spots on images made systematically weaker (and
therefore noisier) by the loss of centring had to be scaled up by
CORRECT/AIMLESS.

 If such is the case with your dataset, there is not much you can
do. Your only hope is to be lucky enough to have enough redundancy in
your raw data that the reflections on the useless images will have
been measured through symmetry equivalents on images for which the
crystal centring was good.

 It could also be that your crystals are very thin plates.


 With best wishes,
 
  Gerard.

--
On Thu, Nov 09, 2017 at 07:53:40PM +, Eleanor Dodson wrote:
> I think you need to look at the images.
> We found one case where the overall Rmerge didnt look too bad but there
> were horrendous streaks across many images. No idea what had happened but
> other crystals from the same batch were much better.
> 
> Eleanor
> 
> On 9 November 2017 at 19:26, CPMAS Chen  wrote:
> 
> > That is right. I had the data already and did not want to throw it away.
> >
> > On Thu, Nov 9, 2017 at 2:09 PM, Eleanor Dodson 
> > wrote:
> >
> >> I think you need to worry about why that has happened, rather than get an
> >> automated rejection criteria!
> >> There must be some problem in the data collection for that to happen..
> >>
> >> Eleanor
> >>
> >> On 9 November 2017 at 19:04, CPMAS Chen  wrote:
> >>
> >>> Hi All,
> >>>
> >>> Is there a way to reject diffraction images based on Rmerge?
> >>>
> >>> When I processed my data with XDS, I use AIMLESS in CCP4 to get merged,
> >>> truncated data. However, there is quite some images with high Rmerge, say
> >>> larger than 1. Is there a keyword I can use to reject these images based a
> >>> Rmerge cut-off, say 0.6?
> >>>
> >>> Thanks!
> >>>
> >>> Charles
> >>>
> >>> --
> >>>
> >>> ***
> >>>
> >>> Charles Chen, Ph. D
> >>>
> >>> Research Associate
> >>>
> >>> University of Pittsburgh School of Medicine
> >>>
> >>> Department of Anesthesiology
> >>>
> >>> **
> >>>
> >>>
> >>
> >
> >
> > --
> >
> > ***
> >
> > Charles Chen
> >
> > Research Associate
> >
> > University of Pittsburgh School of Medicine
> >
> > Department of Anesthesiology
> >
> > **

Re: [ccp4bb] Radiation damage to the FAD in enzyme structure

[Gerard Bricogne]

Dear Martin,

 A more bleeding-edge type of experiment in the vein David is
indicating would be to use a "rotation SFX" protocol to record
complete data off one or very few crystals that will be completely
exempt from radiation damage, as described in doi:10.1038/nmeth.2962
and in doi: 10.1073/pnas.1418733111 .


 Good luck!
 
   Gerard

--
On Mon, Nov 06, 2017 at 08:07:40AM -0500, David Schuller wrote:
> Some alternative interpretations have been suggested, but if you think you
> are seeing radiation damage, you could try collecting data on several
> crystals and binning it by dose received. For comparison see:
> 
> 
> The catalytic pathway of horseradish peroxidase at high resolution.
> Berglund, et al. (23 May, 2002) Nature 417(6887), 463-8
> DOI:
>10.1038/417463a 
> 
> 
> If your low dose and high dose structures appear nearly the same, then you
> are seeing something other than radiation damage.
> 
> 
> 
> On 11/06/17 06:01, Martin Malý wrote:
> > Dear colleagues,
> > 
> > I am investigating a structure of a FAD-dependent enzyme. The electron
> > density map suggests radiation damage to the FAD. It apparently is
> > different from simple change of the redox state and "butterfly"-like
> > structure. We did not find in literature possible products of radiation
> > damage, like a removal of several atoms of the FAD. Has anyone observed
> > such effect?
> > 
> > To describe it in more detail, I can observe negative difference map of
> > C2, N3, C4, and O4 atoms of flavine. Moreover, there is positive
> > difference map close to O2 and O4 atoms thus it looks as water molecules
> > are bound there instead of the missing FAD atoms.
> > 
> > I am attaching parameters of the experiment: performed at synchrotron,
> > exposition time 210 s, high resolution diffraction limit 1.65 A
> > ( = 2 at shell 1.75-1.65 A). We could see a decrease of
> > diffraction data statistics during the experiment hence we think there
> > is significant radiation damage to the crystal.
> > 
> > Thank you very much for ideas.
> > Regards,
> > Martin Maly
> 
> 
> -- 
> ===
> All Things Serve the Beam
> ===
>David J. Schuller
>modern man in a post-modern world
>MacCHESS, Cornell University
>schul...@cornell.edu
> 

Re: [ccp4bb] High R/Rfree after MR

[Gerard Bricogne]

> >>> CCP4BB@JISCMAIL.AC.UK
> >>> 
> >>> 
> >>>   Dear All,
> >>>   I am trying to refine a structure at 3.3A. Model has
> >>>   60% identity to the target. Maps look OK (for 3.3A)
> >>>   and rebuilding in Coot is relatively
> >>>   straightforward. However, after some rebuilding
> >>>   cycles the R factors are stuck at 0.37/0.39
> >>>   (REFMAC). 
> >>>   XTRIAGE tells me that everything is normal (no twin,
> >>>   98% completeness, R=3.5% in the low resolution bin),
> >>>   perhaps some anisotropy is present. 
> >>>   I have already refined 2 homologous structures at
> >>>   resolutions going from 3.2 to 3.8 and there were no
> >>>   problems (final R ~ 0.21/0.24). 
> >>>   Any advice ?
> >>>   Thanks,
> >>>   GIA
> >>> 
> > 
> > -- 
> > Vincent Chaptal, PhD
> > Institut de Biologie et Chimie des Protéines
> > Drug Resistance and Membrane Proteins Laboratory
> > 7 passage du Vercors 
> > 69007 LYON
> > FRANCE
> > +33 4 37 65 29 01
> > http://www.ibcp.fr

-- 

 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===

Re: [ccp4bb] Pilatus Issues

[Gerard Bricogne]

Dear Joe,

 On second thought, it seems to me that a vertical gap would be
even better suited to the use of a 2theta axis than a horizontal one:
if one assumes that the 2-theta axis is parallel to the Omega axis,
i.e. vertical, a small 2-theta offset by at least the angular width of
the gap would suffice to fill it completely, as it would essentially
amount to a horizontal translation. With a horizontal gap, a 2theta
offset mostly slides the gap into itself, and therefore rescues fewer
reflections from having fallen in the gap at 2theta.eq.0 . 

 I am probably missing some fine points that you looked into more
thoroughly.


 With best wishes,
 
  Gerard.

--
On Sun, Jul 16, 2017 at 09:24:41AM +0100, Gerard Bricogne wrote:
> Dear Joe,
> 
>  Thank you for the insights :-) . Near-exclusive exposure to
> synchrotron beamlines leads one to forget about 2theta axes, as they
> are hardly ever encountered; but indeed it is a help here. Most of
> all, I would assume that your default strategies would use several
> *crystal* orientations thanks to your quarter-Chi goniostat. That
> would of course help fill the gap since it amounts to tilting it, but
> even so, it still feels as if more low-resolution reflections would be
> lost because of their proximity to the rotation axis than if the gap
> was mounted vertically. Is that actually not the case?
> 
> 
>  With best wishes,
>  
>   Gerard.
> 
> --
> On Sun, Jul 16, 2017 at 06:19:01AM +, Joseph Ferrara wrote:
> > Gerard,
> > 
> > You are correct that a vertical gap is best when 2theta.eq.0 and we did 
> > explore orienting the Pilatus with the gap vertical early in the hardware 
> > integration process. However, we concluded that when 2theta.ne.0 at least 
> > two 2theta settings would be required to prevent systematically missing 
> > resolution shells. Since most data sets are collected with 2theta.ne.0 we 
> > decided on the horizontal gap in order to distribute the missing data 
> > evenly. Please note the direct beam is not in the gap so low resolution 
> > reflections are accessible.
> > 
> > I would also like to point that a loaner detector was provided to John a 
> > few days ago and we are working with Dectris to sort out the issue that 
> > began this discussion.
> > 
> > Cheers,
> > 
> > Joe Ferrara 
> > 
> > -Original Message-
> > From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of 
> > Gerard Bricogne
> > Sent: Saturday, July 15, 2017 4:31 PM
> > To: CCP4BB@JISCMAIL.AC.UK
> > Subject: Re: [ccp4bb] Pilatus Issues
> > 
> > Dear John,
> > 
> >  Having just seen Andreas's message regarding the best source of 
> > support to address your enquiry, I have a further remark to make about your 
> > instrument.
> > 
> >  As this is a lab instrument, the Omega axis would be vertical, and 
> > indeed the beam stop shadow (vertical on the top module) and the diffuse 
> > shadow of the sample holder (vertical on the bottom module) would confirm 
> > this. This being the case, it is quite simply *daft* to have the gap 
> > between the two modules being horizontal. That is done on purpose on 
> > synchrotron beamlines because of the polarisation of the beam (which is why 
> > Omega is horizontal on such beamlines), but in a lab system the gap should 
> > be in the vertical direction. As currently placed in your system, this gap 
> > is cutting into perfectly good data, whereas if it were vertical instead, 
> > it would only cut out data that are getting perilouly close to the cusp 
> > anyway.
> > 
> >  You should ask the manufacturer of your diffractometer to rotate your 
> > detector by 90 degrees! Someone in the OEM world forgot about the Lorentz 
> > factor ;-) .
> > 
> > 
> >  With best wishes,
> >  
> >   Gerard.
> > 
> > --
> > On Fri, Jul 14, 2017 at 05:14:03PM +0100, John Hardin wrote:
> > > Hi,
> > > 
> > > We have recently noticed an issue with our Pilatus (biased 
> > > pixels/vertical lines).
> > > I was curious as to whether anyone else has seen this or might know what 
> > > could have caused it?
> > > 
> > > Best,
> > > John
> > > 

Re: [ccp4bb] Pilatus Issues

[Gerard Bricogne]

Dear Joe,

 Thank you for the insights :-) . Near-exclusive exposure to
synchrotron beamlines leads one to forget about 2theta axes, as they
are hardly ever encountered; but indeed it is a help here. Most of
all, I would assume that your default strategies would use several
*crystal* orientations thanks to your quarter-Chi goniostat. That
would of course help fill the gap since it amounts to tilting it, but
even so, it still feels as if more low-resolution reflections would be
lost because of their proximity to the rotation axis than if the gap
was mounted vertically. Is that actually not the case?


 With best wishes,
 
  Gerard.

--
On Sun, Jul 16, 2017 at 06:19:01AM +, Joseph Ferrara wrote:
> Gerard,
> 
> You are correct that a vertical gap is best when 2theta.eq.0 and we did 
> explore orienting the Pilatus with the gap vertical early in the hardware 
> integration process. However, we concluded that when 2theta.ne.0 at least two 
> 2theta settings would be required to prevent systematically missing 
> resolution shells. Since most data sets are collected with 2theta.ne.0 we 
> decided on the horizontal gap in order to distribute the missing data evenly. 
> Please note the direct beam is not in the gap so low resolution reflections 
> are accessible.
> 
> I would also like to point that a loaner detector was provided to John a few 
> days ago and we are working with Dectris to sort out the issue that began 
> this discussion.
> 
> Cheers,
> 
> Joe Ferrara 
> 
> -Original Message-
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Gerard 
> Bricogne
> Sent: Saturday, July 15, 2017 4:31 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Pilatus Issues
> 
> Dear John,
> 
>  Having just seen Andreas's message regarding the best source of support 
> to address your enquiry, I have a further remark to make about your 
> instrument.
> 
>  As this is a lab instrument, the Omega axis would be vertical, and 
> indeed the beam stop shadow (vertical on the top module) and the diffuse 
> shadow of the sample holder (vertical on the bottom module) would confirm 
> this. This being the case, it is quite simply *daft* to have the gap between 
> the two modules being horizontal. That is done on purpose on synchrotron 
> beamlines because of the polarisation of the beam (which is why Omega is 
> horizontal on such beamlines), but in a lab system the gap should be in the 
> vertical direction. As currently placed in your system, this gap is cutting 
> into perfectly good data, whereas if it were vertical instead, it would only 
> cut out data that are getting perilouly close to the cusp anyway.
> 
>  You should ask the manufacturer of your diffractometer to rotate your 
> detector by 90 degrees! Someone in the OEM world forgot about the Lorentz 
> factor ;-) .
> 
> 
>  With best wishes,
>  
>   Gerard.
> 
> --
> On Fri, Jul 14, 2017 at 05:14:03PM +0100, John Hardin wrote:
> > Hi,
> > 
> > We have recently noticed an issue with our Pilatus (biased pixels/vertical 
> > lines).
> > I was curious as to whether anyone else has seen this or might know what 
> > could have caused it?
> > 
> > Best,
> > John
> > 

Re: [ccp4bb] Pilatus Issues

[Gerard Bricogne]

Dear John,

 Having just seen Andreas's message regarding the best source of
support to address your enquiry, I have a further remark to make about
your instrument.

 As this is a lab instrument, the Omega axis would be vertical,
and indeed the beam stop shadow (vertical on the top module) and the
diffuse shadow of the sample holder (vertical on the bottom module)
would confirm this. This being the case, it is quite simply *daft* to
have the gap between the two modules being horizontal. That is done on
purpose on synchrotron beamlines because of the polarisation of the
beam (which is why Omega is horizontal on such beamlines), but in a
lab system the gap should be in the vertical direction. As currently
placed in your system, this gap is cutting into perfectly good data,
whereas if it were vertical instead, it would only cut out data that
are getting perilouly close to the cusp anyway.

 You should ask the manufacturer of your diffractometer to rotate
your detector by 90 degrees! Someone in the OEM world forgot about the
Lorentz factor ;-) .


 With best wishes,
 
  Gerard.

--
On Fri, Jul 14, 2017 at 05:14:03PM +0100, John Hardin wrote:
> Hi,
> 
> We have recently noticed an issue with our Pilatus (biased pixels/vertical 
> lines).
> I was curious as to whether anyone else has seen this or might know what 
> could have caused it?
> 
> Best,
> John
> 

Re: [ccp4bb] Fine Phi Slicing

[Gerard Bricogne]

; >> measured, which would not happen for small 2-theta shift.
> >> 
> >> See http://scripts.iucr.org/cgi-bin/paper?BA0020 Figure 16 as excellent 
> >> illustration of this.
> >> 
> >> Biggest risk with this is getting *moving* shadows on the data on the 
> >> second run, as an effective 45-50 degree chi shift (say) will usually be a 
> >> pretty wide opening angle for a kappa gonio. XDS and DIALS both have 
> >> mechanisms to deal with this, and automated processing packages are able 
> >> to apply these given a reasonable understanding of the beamline.
> >> 
> >> Also saves building 2-theta axes which can handle 92 kg ;o)
> >> 
> >> Cheers Graeme
> >> 
> >> On 13 Jul 2017, at 21:00, Keller, Jacob 
> >> <kell...@janelia.hhmi.org<mailto:kell...@janelia.hhmi.org>> wrote:
> >> 
> >> I thought there was a new paper from the Pilatus people saying fine 
> >> slicing is worth it even beyond the original 1/2 mosaicity rule?
> >> 
> >> I would think, actually, more gains would made by doing light exposures 
> >> at, say, 1/3 mosaicity, collecting 360 deg, then shifting the detector in 
> >> 2theta by a degree or two to shift uniformly the spots to new pixels, 
> >> maybe accompanied by a kappa change. One would have to remember about the 
> >> two-theta when processing, however!
> >> 
> >> JPK
> >> 
> >> -Original Message-
> >> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Gerd 
> >> Rosenbaum
> >> Sent: Thursday, July 13, 2017 3:40 PM
> >> To: CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK>
> >> Subject: Re: [ccp4bb] weird diffraction pattern
> >> 
> >> Dear Gerard,
> >> 
> >>  my "sound like a sales person" was meant as poking a little fun - nothing 
> >> serious, of course.
> >> 
> >> I and our users like our not-so-new-anymore Pilatus3 6M. It's a great 
> >> detector in many ways. But, there is a lot of hype that this detector 
> >> solves all-problem, for instance fine slicing that is claimed to be only 
> >> possible with a pixel array detector. People get carried away and use
> >> 0.01 degree slices even as the mosaicity of their sample is, say, 0.3 
> >> degree. Slicing beyond 1/3 of the mosaicity will gain you very little - 
> >> only more frames, more processing time.
> >> 
> >> This discourse is already drifting away from the original topic of the 
> >> thread so I will comment on the other arguments  you made like resolution 
> >> in a private e-mail.
> >> 
> >> Best regards,
> >> 
> >> Gerd
> >> 
> >> On 13.07.2017 14:00, Gerard Bricogne wrote:
> >> Dear Gerd,
> >> 
> >>I can assure you that I have no shares in Dectris nor any
> >> commecial connections with them. What I do have is a lot of still
> >> vivid memories of CCD images, with their wooly point-spread function
> >> that was affected by fine-grained spatial variability as well as by
> >> irredicible inaccuracies in the geometric corrections required to try
> >> and undo the distortions introduced by the fiber-optic taper. By
> >> comparison the pixel-array detectors have a very regular structure, so
> >> that slight deviations from exact registering of the modules can be
> >> calibrated with high accuracy, making it possible to get very small
> >> residuals between calculated and observed spot positions. That, I
> >> certainly never saw with CCD images.
> >> 
> >>I do think that asking for the image width was a highly
> >> pertinent question in this case, that had not been asked. As a
> >> specialist you might know how to use a CCD to good effect in
> >> fine-slicing mode, but it is amazing how many people there are still
> >> out there who are told to use 0.5 or even 1.0 degree image widths.
> >> 
> >>Compensating the poor PSF of a CCD by fine slicing in the
> >> angular dimension is a tall order. With a Pilatus at 350mm from the
> >> crystal, the angular separation between 174-micron pixels is 0.5 
> >> milliradian.
> >> To achieve that separation in the angular (rotation) dimension, the
> >> equivalent image width would have to be 0.03 degree. For an EIGER the
> >> numbers become 75 microns, hence 0.21 milliradian i.e. 0.012 degree.
> >> 
> >>Hence my advice, untainted by any commercial agenda :-) .

Re: [ccp4bb] weird diffraction pattern

[Gerard Bricogne]

Dear Gerd,

 I wasn't really giving much attention to the poke between the
ribs ;-) - for me the more serious matter was to see the merits of
pixel detectors over CCDs made light of, as if they didn't really make
much difference.

 If some people get carried away in the way you describe, well, it
doesn't hurt anyone; but if other people have very small, weakly
diffracting crystals and they are told that they will do as well on a
beamline with a CCD as on one with a Pilatus or an Eiger, then that
will hurt someone.

 The original topic was whether certain images presented without
any information about their angular width and recorded on a CCD were
sufficient to diagnose a diffraction quality problem. As they showed
evidene of at least one long axis, distinguishing streakiness from
plain angular overlap caused by too great an image width seemed the
most natural first step.

 The resolution I was talking about was resolving spots within
images and neighbouring images, either thanks to a detector with a
small PSF or thanks to a very fine image width. CCD detectors are poor
in the first option because of their extended PSF, so emphasis has
always been put on the importance of using the second one when pushed.
Pixel array detectors allow both options to be used simultaneously,
which is especially valuable in the investigation of crystals like
Tang's. Hence, again, my advice in the strict context of the initial
thread. 


 With best wishes,
 
  Gerard.

--
On Thu, Jul 13, 2017 at 02:39:58PM -0500, Gerd Rosenbaum wrote:
> Dear Gerard,
> 
>my "sound like a sales person" was meant as poking a little fun - nothing
> serious, of course.
> 
> I and our users like our not-so-new-anymore Pilatus3 6M. It's a great
> detector in many ways. But, there is a lot of hype that this detector solves
> all-problem, for instance fine slicing that is claimed to be only possible
> with a pixel array detector. People get carried away and use 0.01 degree
> slices even as the mosaicity of their sample is, say, 0.3 degree. Slicing
> beyond 1/3 of the mosaicity will gain you very little - only more frames,
> more processing time.
> 
> This discourse is already drifting away from the original topic of the
> thread so I will comment on the other arguments  you made like resolution in
> a private e-mail.
> 
> Best regards,
> 
> Gerd
> 
> On 13.07.2017 14:00, Gerard Bricogne wrote:
> >Dear Gerd,
> >
> >  I can assure you that I have no shares in Dectris nor any
> >commecial connections with them. What I do have is a lot of still
> >vivid memories of CCD images, with their wooly point-spread function
> >that was affected by fine-grained spatial variability as well as by
> >irredicible inaccuracies in the geometric corrections required to try
> >and undo the distortions introduced by the fiber-optic taper. By
> >comparison the pixel-array detectors have a very regular structure, so
> >that slight deviations from exact registering of the modules can be
> >calibrated with high accuracy, making it possible to get very small
> >residuals between calculated and observed spot positions. That, I
> >certainly never saw with CCD images.
> >
> >  I do think that asking for the image width was a highly pertinent
> >question in this case, that had not been asked. As a specialist you
> >might know how to use a CCD to good effect in fine-slicing mode, but
> >it is amazing how many people there are still out there who are told
> >to use 0.5 or even 1.0 degree image widths.
> >
> >  Compensating the poor PSF of a CCD by fine slicing in the angular
> >dimension is a tall order. With a Pilatus at 350mm from the crystal,
> >the angular separation between 174-micron pixels is 0.5 milliradian.
> >To achieve that separation in the angular (rotation) dimension, the
> >equivalent image width would have to be 0.03 degree. For an EIGER the
> >numbers become 75 microns, hence 0.21 milliradian i.e. 0.012 degree.
> >
> >  Hence my advice, untainted by any commercial agenda :-) .
> >  With best wishes,
> >   Gerard.
> >
> >--
> >On Thu, Jul 13, 2017 at 01:25:08PM -0500, Gerd Rosenbaum wrote:
> >>Dear Gerard,
> >>
> >>you sound like a sales person for Dectris. Fine slicing is perfectly fine
> >>with CCD detectors - it takes a bit longer because of the step scan instead
> >>of continuous scan. The read noise issue is often overstated compared to the
> >>sample induced scatter background. If for fine slicing at 0.05 degree or
> >>less the diffraction peaks go too close to the read noise make a longer
> >>exposure - signal goes up, ratio signal to sample-induced-BG less, as 

Re: [ccp4bb] weird diffraction pattern

[Gerard Bricogne]

Dear Gerd,

 I can assure you that I have no shares in Dectris nor any
commecial connections with them. What I do have is a lot of still
vivid memories of CCD images, with their wooly point-spread function
that was affected by fine-grained spatial variability as well as by 
irredicible inaccuracies in the geometric corrections required to try
and undo the distortions introduced by the fiber-optic taper. By
comparison the pixel-array detectors have a very regular structure, so
that slight deviations from exact registering of the modules can be
calibrated with high accuracy, making it possible to get very small
residuals between calculated and observed spot positions. That, I
certainly never saw with CCD images.

 I do think that asking for the image width was a highly pertinent
question in this case, that had not been asked. As a specialist you
might know how to use a CCD to good effect in fine-slicing mode, but
it is amazing how many people there are still out there who are told
to use 0.5 or even 1.0 degree image widths.

 Compensating the poor PSF of a CCD by fine slicing in the angular
dimension is a tall order. With a Pilatus at 350mm from the crystal,
the angular separation between 174-micron pixels is 0.5 milliradian.
To achieve that separation in the angular (rotation) dimension, the
equivalent image width would have to be 0.03 degree. For an EIGER the
numbers become 75 microns, hence 0.21 milliradian i.e. 0.012 degree.

 Hence my advice, untainted by any commercial agenda :-) .
 
 
 With best wishes,
 
  Gerard.

--
On Thu, Jul 13, 2017 at 01:25:08PM -0500, Gerd Rosenbaum wrote:
> Dear Gerard,
> 
> you sound like a sales person for Dectris. Fine slicing is perfectly fine
> with CCD detectors - it takes a bit longer because of the step scan instead
> of continuous scan. The read noise issue is often overstated compared to the
> sample induced scatter background. If for fine slicing at 0.05 degree or
> less the diffraction peaks go too close to the read noise make a longer
> exposure - signal goes up, ratio signal to sample-induced-BG less, as for
> any fine slicing, same read noise.
> 
> It would be helpful to analyze the dense spot packing along layer lines if
> we knew the wavelength and the sample-to-detector distance (assuming this is
> a 300 mm detector) and the rotation width - as you pointed out. That would
> help to distinguish between multiple crystals (my guess) and lattice
> translocation disorder. Fine slicing is definitely needed to figure out what
> the diffraction pattern at 120 degree could tell you in terms of strong
> anisotropy .
> 
> Best regard.
> 
> Gerd
> 
> On 13.07.2017 08:20, Gerard Bricogne wrote:
> >Dear Tang,
> >
> >  I noticed that your diffraction images seem to have been recorded
> >on a 3x3 CCD detector. With this type of detector, fine slicing is
> >often discouraged (because of the readout noise), and yet with the two
> >long cell axes you have, any form of thick (or only semi-fine) slicing
> >would result in spot overlaps.
> >
> >  What, then, was your image width? Would you have access to a
> >beamline with a Pilatus detector so that you could collect fine-sliced
> >data?
> >
> >  I would tend to agree with Herman that your crystals might be
> >cursed with lattice translocation disorder (LTD), but you might as
> >well try and put every chance of surviving this on your side by making
> >sure that you collect fine-sliced data. LTD plus thick slicing would
> >give you random data along the streaky direction. Use an image width
> >of at most 0.1 degree (0.05 would be better) on a Pilatus, and use XDS
> >to process your images.
> >
> >
> >  Good luck!
> >Gerard
> >
> >--
> >On Thu, Jul 13, 2017 at 01:21:02PM +0100, Tang Chenjun wrote:
> >>Hi David,
> >>Thanks for your comments. Although the spots become streaky in certain 
> >>directions, I have processed the data in HKL3000 and imosflm, which 
> >>suggested the C2221 space group (66.59, 246.95 and 210.17). The 
> >>Rmerge(0.14), completeness(94.8%), redundancy(4.6) are OK. When I tried to 
> >>run Balbes with the solved native structure, the molecular replacement 
> >>solution was poor. So I ran Balbes with the split domains of the native 
> >>structure. Although the solutions were also poor, I found the MR score of 
> >>one solution above 35. On the basis of this solution, I tried to run 
> >>Buccaneer and the Rfree could be 0.46. Unfortunately, there are four 
> >>molecules in the asymmetric unit and it is to hard for me to reduce the 
> >>Rfree further.
> >>
> >>All best,
> >>
> >>Chenjun Tang

Re: [ccp4bb] weird diffraction pattern

[Gerard Bricogne]

Dear Tang,

 I noticed that your diffraction images seem to have been recorded
on a 3x3 CCD detector. With this type of detector, fine slicing is
often discouraged (because of the readout noise), and yet with the two
long cell axes you have, any form of thick (or only semi-fine) slicing
would result in spot overlaps.

 What, then, was your image width? Would you have access to a
beamline with a Pilatus detector so that you could collect fine-sliced
data?

 I would tend to agree with Herman that your crystals might be
cursed with lattice translocation disorder (LTD), but you might as
well try and put every chance of surviving this on your side by making
sure that you collect fine-sliced data. LTD plus thick slicing would
give you random data along the streaky direction. Use an image width
of at most 0.1 degree (0.05 would be better) on a Pilatus, and use XDS
to process your images.


 Good luck!
 
   Gerard

--
On Thu, Jul 13, 2017 at 01:21:02PM +0100, Tang Chenjun wrote:
> Hi David, 
> Thanks for your comments. Although the spots become streaky in certain 
> directions, I have processed the data in HKL3000 and imosflm, which suggested 
> the C2221 space group (66.59, 246.95 and 210.17). The Rmerge(0.14), 
> completeness(94.8%), redundancy(4.6) are OK. When I tried to run Balbes with 
> the solved native structure, the molecular replacement solution was poor. So 
> I ran Balbes with the split domains of the native structure. Although the 
> solutions were also poor, I found the MR score of one solution above 35. On 
> the basis of this solution, I tried to run Buccaneer and the Rfree could be 
> 0.46. Unfortunately, there are four molecules in the asymmetric unit and it 
> is to hard for me to reduce the Rfree further.
> 
> All best,
> 
> Chenjun Tang

-- 

 ===
 *     *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===

[ccp4bb] Coordinated upgrades of the STARANISO server and of autoPROC

[Gerard Bricogne]

Dear all,

 We are pleased to announce coordinated upgrades to STARANISO for
analysis of anisotropy in diffraction data [1] and to autoPROC for
data processing and analysis [2].

 The consistency between the two programs has been increased, so
has the uniformity of output. The final statistics have been gathered
in one place, in the form of both a detailed MRFANA-style table with
numerous resolution bins and an abbreviated AIMLESS-style table with
only "Overall", "InnerShell" and "OuterShell" figures.

 Following its initial use in STARANISO, the binning in spherical
shells is no longer predefined in terms of shells of equal volume, but
is defined dynamically to produce equal numbers of "observations"
(i.e. of reflections after application of the anisotropic resolution
cut-off). This avoids accidentally producing outer-shell statistics
that are so noisy (because that shell is too sparsely populated) as to
be uninformative.

 A clear distinction is made, wherever applicable, between two
types of final statistics:

 * those associated to a conventional treatment, i.e. a cut-off
   based on a spherical average value of I/sig(I) or CC1/2,
   retaining all "measurements" up to that resolution cut-off;
   
 * those produced after the anisotropy analysis in STARANISO, with
   an indication of different resolution limits in different
   directions, and statistics calculated over "observations", i.e.
   only over measurements within the anisotropic cut-off surface,
   or in other words, over significant measurements only.

This leads, in particular, to two distinct values for completeness:
spherical, and ellipsoidal.

 We are putting the last touch to the production of a complete
section of Table 1 (for deposition or publication) containing these
anisotropic data statistics.

 This last version of autoPROC supports the latest XDS (Version
June 1, 2017, BUILT=20170615) and also creates an XML report for data
after anisotropy analysis with STARANISO. This file might not be
completely ISPyB compatible but is intended as a starting point for
discussions regarding the handling and representation of anisotropy in
diffraction data and in processing results derived from them.

 Further details are also available from the release notes at [3].
For any questions please contact us at 

 staraniso at globalphasing dot orgregarding STARANISO
 proc-develop at globalphasing dot com regarding autoPROC


 With best wishes,

The Global Phasing Developers.


[1] http://staraniso.globalphasing.org/
[2] http://www.globalphasing.com/autoproc/
[3] http://www.globalphasing.com/autoproc/news.html

Re: [ccp4bb] Error in assignment of symmetry operators

[Gerard Bricogne]

Dear Radu,

 Nice to know that your problem is sorted and that you are pleased
with the results you are getting from BUSTER.

 Clemens had drafted an answer along exactly the same lines and
circulated it around the team for comments, but we were momentarily
distracted by something else and the CCP4BB experts beat us to it :-) 

 I should say that this is not a representative case: we usually
respond quickly and spare no pains to give users the help they need.


 With best wishes,
 
  Gerard.

--
On Tue, Jun 20, 2017 at 05:02:24PM +0100, r...@mrc-lmb.cam.ac.uk wrote:
> Hi Robbie, Pietro,
> 
> Thank you for the quick replies! I tried this before, but must have messed up
> things afterwards somehow... Anyway, tried again and now Buster works
> beautifully. Indeed the molecule was a couple of unit cells away from the
> origin, as the error message suggests... My fault.
> 
> Best wishes,
> 
> Radu
> 
> 
> > Hi Radu,
> > This may be caused by the coordinates being too many unit cells away from
> the
> > origin. In COOT you can easily ?symmetry move coordinates here?  to a place
> closer to the origin.
> > Hope this helps,
> > Robbie
> > Sent from my Windows 10 phone
> > Van: r...@mrc-lmb.cam.ac.uk
> > Verzonden: dinsdag 20 juni 2017 16:14
> > Aan: CCP4BB@JISCMAIL.AC.UK
> > Onderwerp: [ccp4bb] Error in assignment of symmetry operators
> > Dear All,
> > Apologies for posting a Buster-related question to this list, the
> buster-discuss one seems less active :-) I am trying to run a refinement
> job,
> > and hit the following problem:
> > ERROR : [run_buster-0046] unable to create initial SCREEN
> > output with gelly - see
> > refine/01-BUSTER/Cycle-1/gelly_screen.log)
> > Looking in the gelly_screen.log, the problem reported is:
> >  Getting symmetry operators from TNT.
> >  gelly will classify symmetry using pdb-like convention:
> >   SYMOP   SYMMETRY
> >  NNNMMM   OPERATOR
> >1555   X,Y,Z
> >2555   -X,Y,-Z
> >3555   1/2+X,1/2+Y,Z
> >4555   1/2-X,1/2+Y,-Z
> >  where NNN -> operator number and MMM -> translation vector
> > *** ERROR in assignment of symmetry operators NNNMMM (M<1 or M>9). *** ERROR
> maybe the molecules are far away from the origin.
> > I tried everything I could think of to fix this, no luck so far I'm
> probably making a very silly mistake... But would be very grateful for any
> advice!
> > Best wishes,
> > Radu
> > PS: space group is C2
> > --
> > Radu Aricescu
> > MRC Laboratory of Molecular Biology
> > Francis Crick Avenue
> > Cambridge Biomedical Campus
> > Cambridge CB2 0QH, U.K.
> > tel: +44-(0)1223-267049
> > fax: +44-(0)1223-268305
> > www: http://www2.mrc-lmb.cam.ac.uk/group-leaders/a-to-g/radu-aricescu

Re: [ccp4bb] What are acceptable Rwork/Rfree for publication

[Gerard Bricogne]

Dear Khoa,

 You are asking a very pertinent question, that will resonate in
(too) many people's minds.

 Somehow anisotropy is very much "an inconvenient truth" in MX, as
many things have long been set up and operated on the basis of having
resolution be a single number and of all statistics being calculated
in spherical shells, throwing in everything that has an HKL associated
with it. We are repeatedly told that resolution *has* to be a single
number, because the title of a Nature paper only has room for one
number - if that isn't a case of the tail wagging the dog, I don't
know what is ;-) . 

 There are more serious contexts in which the requirement for a
single number can be a more complex issue, such as contractual
arrangements where the achievement of certain milestones and the 
remuneration attached to them depend on reaching a certain resolution.
Here, whoever writes and/or accepts resolution criteria of this kind
will simply have to undergo further education and learn about that
inconvenient fact called anisotropy. Probably - especially in the case
of membrane protein structures - it is the highest resolution limit
that matters; but you can't have good completeness to that highest
resolution, by the very definition of anisotropy! Therefore, some
quality criteria that are compatible in the case of isotropic data can
become contradictory for anisotropic data, and force absurd decisions
to be made that result in the discarding of perfectly good data in
order to get back to a pseudo-isotropic situation.

 Your question is very timely as well, as we are about to announce
a new version of the STARANISO server in which we have made an effort
to address these questions. You say you have used the UCLA server: it
is a fine resource, that has served the community for over a decade,
but there are limitations in its treatment of anisotropy, especially
in low-symmetry cases. Your structure is in C2, and if you look at the
example of a C2 structure at 

 http://staraniso.globalphasing.org/anisotropy_about.html

and especially at the picture at 

 http://staraniso.globalphasing.org/pereda.png

you will see that anisotropy can be such that it cannot be described
as separate effects along the individual crystallographic axes: in
this case, the principal directions are along the bisectors and not
along the axes, and a product of separate corrections along the two
axes would do a very bad job indeed. This is why I think you should
submit your data to the STARANISO server as well. You may also find
the interactive 3D display of the local average of I/sig(I) quite
informative about possible infelicities in your dataset.

 Returning to a broader perspective, one thing should be clear:
there cannot be any good reason, based on downstream considerations
(such as what the PDB is prepared to accept, or there being room for
only a single number in manuscript titles and outsourcing contracts),
for throwing away data that are, as judged by a 3D local average of
I/sig(I), significantly above noise. The mission of data processing is
to capture every bit of information present in the raw images, without
any censorship originating from what may happen further downstream as
a result of anisotropy. All entities concerned (PDB, reviewers, legal
departments) will simply have to change their mental habits in order
to accommodate the inconvenient existence of anisotropy, as it is here
to stay :-) . In fact it has always been there, but has become harder
to ignore.


 With best wishes,
 
  Gerard.

--
On Sun, Jun 18, 2017 at 11:52:34AM +, Khoa Pham wrote:
> Dear Gerard,
> 
> Thank you very much for your suggestions. 
> We actually analyzed anisotropy of the data using UCLA-DOE LAB Diffraction 
> Anisotropy Server https://services.mbi.ucla.edu/anisoscale/. The question is 
> that if the data cut in the anisotropically way, should it be deposited to 
> the pdb.
> 
> Sincerely,
> 
> Khoa Pham

-- 

 ===
 *         *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===

Re: [ccp4bb] What are acceptable Rwork/Rfree for publication

[Gerard Bricogne]

Dear Khoa,

 Thank you for your reply and for the news that your data do show
strong anisotropy.

 In such cases, the reflex is indeed to cut the data down to a
resolution where the statistics look more reasonable. However, as
these statistics are computed in spherical shells, i.e. continue to
include data in the weak directions, getting those reasonable values
necessarily entails rejecting significant data in the best directions.

 The analysis of anisotropy done by the STARANISO server I pointed
you to will avoid this rejection: it will instead discard all the
pure-noise data so that your model will be refined (and hence the Fc
compared to Fo to calculate the statistics) only for data that are
significantly above noise. As you are a newcomer, you might find the
following introductory material useful:

   http://staraniso.globalphasing.org/anisotropy_about.html

 I therefore strongly advise you to submit your data to the server
and to keep in touch off-list for any extra advice you might need.


 With best wishes,
 
  Gerard.

--
On Sun, Jun 18, 2017 at 02:29:06AM +, Khoa Pham wrote:
> Dear Gerard and James,
> 
> Thank you very much for the suggestions.  My data was collected at APS. 
> Yesterday, an expert in my institution kindly inspected my raw data and 
> pointed out to me that my data are indeed severely anisotropic in the b 
> direction. He also recommended me to cut the data to 3.27 A (or lower). I 
> took his advise and tried refining the data with a resolution of 3.27 A. I 
> found that it indeed reduced the values of Rwork/Rfree too much more 
> reasonable window (0.264/0.322, respectively). I will try improving the 
> quality of my crystals and hope to collect better data sets.
> 
> I am a new comer to protein crystallography. I appreciate all for giving me 
> valuable advises.
> 
> Sincerely,
> 
> Khoa Pham

Re: [ccp4bb] What are acceptable Rwork/Rfree for publication

[Gerard Bricogne]

Dear Khoa,

 I would lean in the same direction as James, and say that what
you need is not advice about what refinement program to use, but a
question about whether you could collect better data. With an overall
I/sig(I) of 8.3 and an outer-shell value of 0.5, there is just not
enough oomph in your data, and you might essentially be flogging a
dead horse. 

 A low symmetry like C2 leaves room for a lot of anisotropy, so
you might want to give a try to the server at 

  http://staraniso.globalphasing.org/cgi-bin/staraniso.cgi

This will probably not rescue your dataset, but it may give you some
indications that perhaps it is anisotropy that is bringing the shell
average of I/sig(I) to as low a value as 0.5, and that there may be
decently strong data to a certain resolution in some directions that
are getting swamped by noisy data in other directions.


 With best wishes,
 
   Gerard.

--
On Sat, Jun 17, 2017 at 03:55:15PM -0500, James Phillips wrote:
> I am not happy with an Rmerge of 20%. Also what is the Rmerge and
> redundancy in the highest shell, i.e. do you really have the resolution of
> 2.9?
> 
> How did you collect this data? SR or lab.
> 
> 
> 
> James Phillips
> 
> On Wed, Jun 14, 2017 at 8:09 AM, Khoa Pham <khoa.p...@einstein.yu.edu>
> wrote:
> 
> > Dear CCP4 members,
> >
> > I am refining a structure with a resolution of ~ 2.9 A and the Rwork/Rfree
> > are are 0.34/0.37, respectively.
> > My question is that these Rwork/Rfree are acceptable for publication. If
> > not, how can I reduce them?
> >
> > Thank you.
> >
> > Khoa
> >
> > The table of statics.
> >
> > Space group
> >
> > C121
> >
> >
> > Resolution (Å)
> >
> > 29.69-2.92
> >
> > No of unique reflections
> >
> > 61569 (8747)
> >
> > Rmerge (%)
> >
> > 20 (350)
> >
> > Rpim (%)
> >
> > 11 (198)
> >
> > I/s(I)
> >
> > 8.3 (0.5)
> >
> > CC1/2
> >
> > 0.99 (0.33)
> >
> > CCanomalous
> >
> > N/A
> >
> > Completeness (%)
> >
> > 98.5 (95.8)
> >
> > Redundancy
> >
> > 4.2 (4.0)
> >
> >
> >
> >
> >
> > *Refinement*
> >
> >
> >
> > Resolution (Å)
> >
> > 29.69-2.92
> >
> > No of reflections
> >
> > 58394 (4069)
> >
> > Rwork/Rfree
> >
> > 0.3380/0.3689
> >
> >
> > R.m.s. deviations
> >
> >
> >
> >Bond lengths (Å)
> >
> > 0.0073
> >
> >Bond angles (o)
> >
> > 1.1062
> >
> >
> >

-- 

 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===

Re: [ccp4bb] Refining a crystal structure with (very) high solvent content

[Gerard Bricogne]

Dear Eleanor,

 I think this is too faint a praise for Dale. What he shows in his
reply is not just common sense, but knowledge and understanding of the
fundamentals. You can't do good science with common sense alone, and
in our field common sense will not be of much help if you do not
understand the Fourier transform well enough, for example.

 I would venture to guess that 95+% of crystallographers are in
the unquestioned habit of making the same conceptual error that Dale
has pointed out, viz. mistaking the rmsd of the map (which is a unit
of contrast) for the standard deviation of a noise level in the map.
The latter quantity has nothing to do with the former, as has been
pointed out many times.

 The problem is that this confusion is enshrined in the default
values of certain parameters in display programs and scripts, that are
assumed (not by their authors, but by almost everybody else) to embody
all the common sense we need :-) .


 With best wishes,
 
  Gerard.

--
On Sun, Jun 04, 2017 at 03:36:29PM +0100, Eleanor Dodson wrote:
> Thank you Dale! You talk so much common sense..
> Eleanor
> 
> On 2 June 2017 at 23:30, Dale Tronrud  wrote:
> 
> > On 6/2/2017 1:42 PM, wtempel wrote:
> > > Hello all,
> > > crystals with high solvent content tend to diffract poorly, at least
> > > according to intuition. Several years ago we solved a structure
> > >  that
> > > appeared to buck that trend with a solvent content of ≈0.8 and
> > > resolution beyond 2 Å, per merging statistics and visibility of spots on
> > > diffraction images.
> > > I would welcome my colleagues’ opinions as to why I might observe the
> > > following:
> > >
> > >  1. Paired refinement (similar to Fig. 1 in Karplus
> > > ) indicates that adding any
> > > higher resolution data beyond 3.4 Å, the lowest high resolution
> > > cut-off limit I tried, does not improve R-factors at the common
> > > lower resolution cutoff. Yes, diffraction is anisotropic in this
> > > case, but seemingly not to that extent. I hesitate to “throw out”
> > > all data beyond 3.4 Å, or whatever lower resolution cut-off I might
> > try.
> > >  2. The Fo-Fc map, when countoured at ± 3 rmsd, includes many more
> > > (uninterpretable) features than I would expect after refinement to
> > > residuals in the mid-to-lower twenties. For expected map appearance,
> > > I had to crank up the coutour level to > 5 rmsd, like in the
> > > attached screenshot of the ADP·Mg^++ omit map.
> >
> >This is one of the prime examples of the failure of describing
> > contour levels in terms of "sigma".  First, the number you are using is
> > not a "standard deviation" or any other measure of the error level of
> > the map but is simply the rms value of the map.  If you calculate the
> > rms of a difference map where 80% of the unit cell is bulk solvent, and
> > therefore flat, you will, of course, get a much smaller number than if
> > the unit cell contained 80% protein with all the the expected difference
> > map features that come from a model with an R value of ~20%.  Then when
> > you contour at three times this absurdly small number you will see all
> > sorts of features you are not used to seeing.  Selecting a contour level
> > based on the e/A^3 is much less sensitive to the amount of solvent in
> > the crystal is gives much more consistent results.
> >
> > Dale Tronrud
> > >
> > > Could these observations be linked to the high solvent content? (1) A
> > > high solvent content structure has a higher-than-average
> > > observation-to-parameter ratio, sufficiently high even when limited to
> > > stronger, low-resolution reflections? (2) Map normalization may not be
> > > attuned to such high solvent content?
> > > I am interested in analyzing the automated decision-making of the
> > > PDB-REDO of this entry , such as
> > > paired refinement results and selection of ADP model. Should I find this
> > > information in the “All files (compressed)” archive
> > > ? The “fully
> > > optimized structure’
> > >  shows |ANISOU|
> > > cards and |NUMBER OF TLS GROUPS : NULL|. Does this mean that individual
> > > ADPs have been refined anisotropically?
> > > Looking forward to your insights,
> > > Wolfram Tempel
> > >
> > > ​

Re: [ccp4bb] Molrep

[Gerard Bricogne]

Dear Fred,

 Have you tried putting your data through the STARANISO server at 
 
 http://staraniso.globalphasing.org  ?


 With best wishes,
 
  Gerard.

--
On Thu, May 25, 2017 at 07:28:50PM -0400, Dyda wrote:
> Dear All,
> 
> Does anyone know by any chance what to do when Molrep crashes with:
> 
>   Radius of gyration  :   27.85
>   WARNING: Radius of integration  >42.40
>   Radius of integration   :   42.40
>   Resolution  :   29.824.00
>  --- rfcoef for model ---
>  --- rfcoef for Fobs ---
>   NCS (from Self rotation Function): 1
>   ERROR: in RFROT: RF overflow
>   ERR: in CALC_SRF
> 
> This is with "anisothermal correction of Fobs" whatever that means.
> 
> It runs fine with "default scaling".
> 
> Data are very anisotropic, so "anisothermal correction of Fobs" sounded 
> attractive.  
> 
> Thanks.
> 
> Fred
> ***
> Fred Dyda, Ph.D.   Phone:301-402-4496
> Laboratory of Molecular BiologyFax: 301-496-0201
> DHHS/NIH/NIDDK e-mail:fred.d...@nih.gov  
> Bldg. 5. Room 303 
> Bethesda, MD 20892-0560  URGENT message e-mail: 2022476...@mms.att.net
> Google maps coords: 39.000597, -77.102102
> http://www2.niddk.nih.gov/NIDDKLabs/IntramuralFaculty/DydaFred
> ***

-- 

 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===

Re: [ccp4bb] peroxy-glutamate?

[Gerard Bricogne]

Dear Ed,

 Thank you for the picture. The decarboxylation of GLU and ASP
side-chains is perhaps the most ubiquitous manifestation of radiation
damage. We have introduced a feature in our autoPROC processing
package whereby, if redundancy in the unmerged data is sufficient to
allow reasonably complete and non-overlapping "early" and "late"
data(sub)sets to be defined, we output "early-minus-late" difference
coefficients that can later be picked up by autoBUSTER to compute the
corresponding difference map. This is a great way of pin-pointing
acidic side-chains, and also sulphur-containing ones. I am sure others
are certain to propose a cooler name for that very same type of map
some day ;-) .

 Here, you seem to have a clear case of partial decarboxylation.
You could try reprocessing your images with autoPROC and computing an
early-minus-late map, just to see what it looks like. If your dataset
complies with the modern low-transmission, high-redundancy paradigm,
it should be very straightforward. You are welcome to get in touch
off-list about this.


 With best wishes,
 
  Gerard.

--
On Wed, May 03, 2017 at 05:19:25PM -0400, Edward A. Berry wrote:
> 
> 
> On 05/03/2017 02:46 PM, Gerard Bricogne wrote:
> >Dear Ed,
> >
> >  Have you considered the possibility that it could be a water
> >stepping in to fill the void created by partial decarboxylation of the
> >glutamate? That could be easily modelled, refined, and tested for its
> >ability to flatten the difference map.
> >
> >  Gerard.
> >
> Actually some of them do appear decarboxylated. Is that something that can 
> happen? In the crystal, or as radiation damage?
> However when there is density for the carboxylate (figure), it appears 
> continuous and linear, doesn't break up into spheres at H-bonding distance - 
> almost like the CO2 is still sitting there- but I guess it would get hydrated 
> to bicarbonate. I could use azide. Or maybe waters with some disorder.
> Thanks,
> eab
> 
> Figure- 2mFo-DFc at 1.3 sigma, mFo-DFc at 3 sigma, green CO2 is shown for 
> comparison, not part of the model.
> 

Re: [ccp4bb] peroxy-glutamate?

[Gerard Bricogne]

Dear Ed,

 Have you considered the possibility that it could be a water
stepping in to fill the void created by partial decarboxylation of the
glutamate? That could be easily modelled, refined, and tested for its
ability to flatten the difference map.

 Gerard.

--
On Wed, May 03, 2017 at 02:29:11PM -0400, Edward A. Berry wrote:
> Thanks to all who replied. Yes, in some of the other cases density between Cd 
> and Cg is conspicuously weak. From preliminary tests it looks like dual 
> conformations, in some cases together with correlated waters, will account 
> for the density adequately. No Zebras here!
> eab
> 
> On 05/03/2017 04:26 AM, Matthew Merski wrote:
> >Have you tried just a double conformation of the Glu?  Its hard to tell in 
> >your pictures but it looks like there might be less than perfect density for 
> >the CG-CD bond?  If you just try adding a second conf of the Glu that might 
> >work too (and perhaps be a horse rather than a zebra making your hoofprints?)
> >
> >Matthew Merski
> >Crystallochemistry Laboratory
> >Univ. of Warsaw
> >
> >On Wed, May 3, 2017 at 6:29 AM, Edward A. Berry  >> wrote:
> >
> >I'm finishing up refinement of a 1.8A structure (R's 0.17, 0.20) , and 
> > among the largest peaks in the difference map are small spherical blobs 
> > that seem to be attached (1.46 A here) to carboxylate O's (Figures). Are 
> > these likely artifacts? If not, how can I interpret/model them? One idea is 
> > that the acid has reacted with peroxide from the PEG to make the 
> > (hydro)peroxy-acid. I don't know how stable that would be, and I don't see 
> > any peroxyglutamate in Ligand Depot or HIC-Up. Another guess would be acid 
> > hydroxamate but I don't know how that would be generated. Methyl ester 
> > seems to be ruled out by the proximity of the two water molecules (2.45 and 
> > 2.48 A here) suggesting the mystery atom is an H-bond acceptor or donor. 
> > However since the occupancy seems to be < 1, the waters may be there only 
> > when the atom is not.
> >I guess another possibility is there is a lot of motion in the plane of 
> > the carboxylate (up and down here) which cannot be modeled by my isotropic 
> > B-factors. In some cases the green blobs appear on both sides of the 
> > carboxylate (but that could also be alternate conformations of 
> > peroxyglutamate).
> >
> >The difference map (mFo-DFc, green) is contoured at 3 sigma (.06 
> > e-/A^3). The difference peak is 5.4 sigma (0.1 e/A3).
> >The 2mFo-DFc map is contoured at 1.5 sigma (0.1 e/A3). 2mFo-DFc density 
> > extends to the difference peak if I contour down at 0.64 sigma (0.04 e/A3, 
> > third figure).
> >
> >If I put an O atom there, link it with plenty of slack, and refine 
> > occupancy, it goes to 1.54 A from the carboxylate O and refines to 
> > occupancy 0.35, B-factor 15 (carboxylate O is 30). Now it is reached by 
> > 2mFo-DFc density at 1.5 sigma (0.1 e/A3).
> >Any suggestions would be welcome.
> >eab

[ccp4bb] Major upgrade of the STARANISO server

[Gerard Bricogne]

Dear all,

 The STARANISO server has now successfully processed over 1000
user-submitted datasets since it was launched in January last year.

 We are pleased to announce a major upgrade to this server:

* it now supports submissions of unscaled and unmerged intensity data
  (as well as the already available input mode for merged intensity
  data) and performs an analysis of anisotropy as part of the scaling
  and merging process;

* the documentation on the server concerning anisotropy in general and
  its treatment in STARANISO has been greatly expanded and includes a
  glossary for all the terminology used;

* similarly, the logfile now includes careful specifications for the
  various types of statistics (some of them, unfamiliar) it presents.

 We are still working hard on producing a template (with examples)
for an "anisotropy aware" Table 1, as well as an FAQ, but we thought
that now would be a good time to solicit a first round of feedback
from the user community: please connect to

 http://staraniso.globalphasing.org/cgi-bin/staraniso.cgi


 Ian Tickle and the Global Phasing developers.

Re: [ccp4bb] Composit omit map vs. ligand

[Gerard Bricogne]

Dear Pavel,

 Thank you for your reply. I would have thought that many of your
users in the drug discovery field would have been aware of it, as many
of them use both Phenix and BUSTER.
 
 An even more explicit and detailed description of that feature,
dated March 2011, may be found at
 
http://www.globalphasing.com/buster/wiki/index.cgi?LigandDetectionModes


 With best wishes,
 
  Gerard.

--
On Thu, Feb 16, 2017 at 07:17:23AM -0800, Pavel Afonine wrote:
> Dear Gerard,
> Thank you so much for letting us know of the reference and details about
> your long-standing BUSTER method for ligand density maps which we now see
> is very similar to our recent polder map method.  We apologize for not
> being aware of the early reference and we will be very sure to cite it in
> future publications.
> Very best regards,
> Pavel
> 
> 
> On Thu, Feb 16, 2017 at 5:35 AM, Gerard Bricogne <g...@globalphasing.com>
> wrote:
> 
> > Dear Pavel,
> >
> >  As much as I would have wished to, I was unable to contribute to
> > this thread for the past week because of more pressing matters. I hope
> > it hasn't entirely gone cold in the minds of CCP4BB readers.
> >
> >  I want to congratulate the Phenix developers for having come up
> > with such a catchy name for a method that was first conceived, and
> > implemented in autoBUSTER, by Clemens Vonrhein over 12 years ago, and
> > has been abundantly exercised and appreciated for its usefulness by
> > its users (especially, drug discovery companies) ever since.
> >
> >  You do mention BUSTER:
> >
> >   The program BUSTER (Bricogne et al., 2016) allows the exclusion of
> >   regions from bulk solvent by processing an additional file which
> >   describes the binding site (without resembling the putative ligand).
> >   Furthermore, statistical treatment of non-uniformity of bulk solvent
> >   or as yet unmodeled regions has been discussed ... [with two more
> >   BUSTER-related references dated 2000 and 2004]
> >
> > but the 2016 date (which is the one we recommend that users cite for
> > the latest version of the program) rather obliterates any sense of
> > chronology when it comes to the specific underlying idea of "Polder
> > maps" and of its prior implementation mentioned above.
> >
> >  We (here) can certainly not claim to be champions when it comes
> > to publicizing our work through the usual channel of polished academic
> > publications, as our lives as developers are driven and dominated by
> > rather different imperatives. However there happens to be an official
> > record of the origins of that method in
> >
> >  http://journals.iucr.org/a/issues/2005/a1/00/a32958/a32958.pdf
> >
> > or (for a prettier format)
> >
> >  http://dx.doi.org/10.1107/S0108767305089415
> >
> >  To complete that record: this development was released to our
> > Consortium members in November 2003, and to academic users at large in
> > July 2009. It is described in quite explicit terms in the online
> > documentation we later wrote for academic users and posted on our
> > external Wiki, e.g.
> >
> > http://web.archive.org/web/20121216164211/http://www.
> > globalphasing.com/buster/manual/autobuster/manual/autoBUSTER5.html
> >
> >  In spite of the lack of a standard academic reference, this
> > feature has therefore been an open secret for a very long time under
> > the name of "the -L option" in autoBUSTER, where L stands for "ligand
> > chasing".
> >
> >
> >  So, again, congratulations for finding such a good name for the
> > method and for publishing a collection of nicely illustrated examples
> > of its usefulness. Your presentation, however, might be seen as rather
> > economical in its acknowledgment of "prior art" - a notion that surely
> > has to be recognised as existing outside the confines of standard,
> > neatly packaged, immediately quotable Acta D publications :-) .
> >
> >
> >  With best wishes,
> >
> >   Gerard.
> >
> > --
> > On Thu, Feb 09, 2017 at 03:45:22PM -0800, Pavel Afonine wrote:
> > > In addition to excellent Kay's reply..
> > >
> > > Also make sure to check refined B factors. Note, if the ligand is not
> > there
> > > then that volume is likely filled with bulk-solvent. Now low occupancy in
> > > combination with very large B factors may approximate bulk-solvent quite
> > > well. The Polder map along with three CC values that its calculation
> &g

Re: [ccp4bb] Composit omit map vs. ligand

[Gerard Bricogne]

aset with potential enzyme:ligand complex at 2.2 AA
> > >resolution. The ligand is very good substrate for the enzyme, we used
> > >soaking. We do not see the ligand in the regular difference electron
> > >density, only five out of twenty atoms. However, the ligand placed at
> > >the active site (model used from structure of a mutant variant) is
> > >refined well, giving no negative peaks in difference electron density
> > >map and nice observed electron density. I have calculated composit omit
> > >map with annealing in Phenix (input model did not contain the ligand)
> > >and the electron density for the ligand is there.
> > >
> > >I have my own opinion, but we are desperate to obtain such data (more
> > >than 40 crystals already tested). My question is, would this be proof of
> > >presence of the ligand with reduced occupancy? Will this map convince
> > >the reviewers? Is there any other way to validate presence of the ligand?
> > >
> > >Best regards,
> > >Petr
> > 

--

 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===

Re: [ccp4bb] Rfree below Rwork

[Gerard Bricogne]

Dear Wolfram,

 I have a perhaps optimistic view of the effect of high-order NCS
on Rfree, in the sense that I don't view it as a problem. People
have agonised to extreme degrees over the difficulty of choosing a
free set of reflections that would produce the expected gap between
Rwork and Rfree, and some of the conclusions were that you would need
to hide almost half of your data in some cases!

 I think it is best to remember that the idea of cross-validation
by Rfree is to prevent overfitting, i.e. ending up with a model that
fits the amplitudes too well compared to how well it determines the
phases. In the case of high-order NCS (in your case, the U/V ratio
that the old papers on NCS identified as the key quantity to measure
the phasing power of NCS would be less than 0.1!) the phases and the
amplitudes are so tightly coupled that it is simply impossible to fit
the amplitudes without delivering phases of an equally good quality.
In other words there is no overfitting problem (provided you do have
good and complete data) and the difference between Rfree and Rwork is
simply within the bounds of the statistical spread of Rfree depending
on the free set chosen.

 You are lucky to have 6-fold NCS, so don't let any reviewer
convince you that it is a curse, and make you suffer for it :-) .


 With best wishes,
 
  Gerard.

--
On Tue, Jun 30, 2015 at 12:58:44PM -0400, wtempel wrote:
 Hello,
 my question concerns refinement of a structure with 6-fold NCS (local
 automatic restraints in REFMAC) against 2.8 A data. The size of my free set
 is 1172 selected in thin resolution shells (SFTOOLS) and corresponding to
 4.3 % of reflections.
 A refmac run of 10 cycles of TLS and 10 cycles of CGMAT starts out at
 Rfree/Rcryst 0.271/0.272. After the 10th TLS cycle I have 0.227/0.224. Yes,
 Rfree  Rcryst. At the end of CGMAT I have 0.2072/0.2071.
 I understand that NCS stresses the independence assumption of the free set.
 Am I correct in believing that Rfree *may* be smaller than Rcryst even in
 the absence of a major mistake? My hope is that the combined wisdom of
 ccp4bb followers can point out my possible mistake,  suggest tests that I
 may perform to avoid them and, possibly, arguments in defense of a
 crystallographic model with Rfree  Rcryst.
 Many thanks,
 Wolfram Tempel

-- 

 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===