Dear Gerard, I was puzzled by the statement that the UCLA anisotropy server characterises anisotropy in terms of a combination of effects restricted to lie along the crystallographic axes. That server is built on the anisotropy correction algorithm in Phaser, and from the beginning Phaser has used an anisotropic tensor that is constrained only by the Laue symmetry. I've been in touch with Mike Sawaya to clarify whether they were doing anything different. Perhaps he will comment directly, but he said that their server indeed uses the general ellipsoid for the anisotropic truncation. The confusion arises from a simplified description on their results page, which describes the principal axes in terms of which reciprocal cell edge is closest.
In seeking to clarify exactly what the server is doing, I attempted to track down the example underlying the illustration on the STARANISO web page. I believe that this is PDB entry 5j1i, but it is not possible to repeat the calculations with the data deposited in the PDB because what has been deposited appears to be the anisotropy-corrected, truncated data used in refinement. This brings up an important point. I am confident you would agree with me that, in cases such as this, the uncorrected, untruncated data should always be deposited as well as any massaged data used for refinement. Once an anisotropy correction has been applied, the systematically weak data may not contribute any useful information to the refinement, but those data provided essential information to the characterisation of anisotropy. Without access to those weak intensities, it becomes impossible to make use of new information (e.g. from the atomic model) or to apply any new, improved algorithms for analysing anisotropy. Similar issues are even more important for the treatment of the systematically weak intensities arising from translational non-crystallographic symmetry (tNCS). By the way, we have a rather different reflection-by-reflection approach to data truncation in Phaser, implemented last year but not yet published. After characterising the anisotropy and (if present) tNCS, we determine how much information (measured in bits) each intensity measurement contains, relative to what was expected from the Wilson distribution. By default, reflections that contribute less than 0.01 bits of information are omitted from any subsequent calculations, though we do not truncate them from the output reflection list. In some data sets with severe anisotropy and/or tNCS, over 40% of the reflections are omitted. Importantly, we could not have characterised the anisotropy and tNCS without having those extremely weak measurements included in the data set! We feel that the reflection-by-reflection approach has the advantage that the significant number of reflections with some signal that will be found beyond any hard limit can still be included, without a large increase in computational cost. It's also worth reminding the community that if the French & Wilson algorithm has been applied without accounting for anisotropy and tNCS, the resulting amplitudes will significantly over-estimate the systematically weak reflections. That's another reason to strongly encourage everyone to deposit their data in terms of intensities and their standard deviations (as discussed here: http://scripts.iucr.org/cgi-bin/paper?S2059798315013236 <http://scripts.iucr.org/cgi-bin/paper?S2059798315013236>). Best wishes, Randy > On 18 Jun 2017, at 13:58, Gerard Bricogne <g...@globalphasing.com> wrote: > > 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 +0000, 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 * > * * > =============================================================== ------ Randy J. Read Department of Haematology, University of Cambridge Cambridge Institute for Medical Research Tel: + 44 1223 336500 Wellcome Trust/MRC Building Fax: + 44 1223 336827 Hills Road E-mail: rj...@cam.ac.uk Cambridge CB2 0XY, U.K. www-structmed.cimr.cam.ac.uk
