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 +0000, 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 conditions. He then proposed sharpening the data in the
> weaker directions to the same fall-off profile as the best direction after
> applying the anisotropic cut-off, and reported that the resulting map was
> much more interpretable. STARANISO does the same by default, as specified by
> a pre-checked button on the server's submission page; however this button
> carries the following annotation:
>
> "Perform anisotropic correction of output intensities and amplitudes
> (default): uncheck only if anisotropic correction is not required (not
> recommended)."
>
> and thus allows a user to override that default.
>
>
> > Just a short comment to your table in the attachment. In case of BO from
> > our publication, STARANISO resolution goes to 2.3, but our suggestion was
> > to stop at the original resolution of 2.6 AA. The reason for that is
> > sub-optimal refinement of the geometry. Once restrained 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 <CCP4BB@JISCMAIL.AC.UK> on behalf of Gerard
> > Bricogne <g...@globalphasing.com>
> > 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 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 Gerard.
> >
> >
> > [1] Tickle, I.J., Flensburg, C., Keller, P., Paciorek, W., Sharff, A.,
> > Vonrhein, C., Bricogne, G. (2018). STARANISO. Cambridge, United
> > Kingdom: Global Phasing Ltd.
> >
> > https://www.jiscmail.ac.uk/cgi-bin/wa-jisc.exe?A2=ind1806&L=CCP4BB&O=D&P=3971
> >
> > [2] https://staraniso.globalphasing.org/
> >
> > [3] https://doi.org/10.1107/s0907444911007773
> > https://www.globalphasing.com/autoproc/
> >
> >
> > ########################################################################
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
> >
> > This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing
> > list hosted by www.jiscmail.ac.uk, terms & conditions are available at
> > https://www.jiscmail.ac.uk/policyandsecurity/
>
> ########################################################################
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
>
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at
> https://www.jiscmail.ac.uk/policyandsecurity/
########################################################################
To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list
hosted by www.jiscmail.ac.uk, terms & conditions are available at
https://www.jiscmail.ac.uk/policyandsecurity/
