[phenixbb] Fwd: Geometry Restraints - Anisotropic truncation

Thu May 3 08:05:34 PDT 2012

Hi Tom,
Do you think something like this could be used during refinement to identify the "best" resolution limits? If you have an Rsleep set would Rfree be sufficient for this? I imagine  collecting data with a ring of noise and then let the optimal resolution be determined during refinement. My understanding of this is that the modern refinement algorithms can handle some noise in the reflections, but maybe this could be a way to optimize how much signal is needed to contribute in a positive fashion?
Kendall

From: "Terwilliger, Thomas C" <terwilliger at lanl.gov<mailto:terwilliger at lanl.gov>>
Date: May 3, 2012 10:23:29 AM EDT
To: PHENIX user mailing list <phenixbb at phenix-online.org<mailto:phenixbb at phenix-online.org>>
Subject: Re: [phenixbb] Geometry Restraints - Anisotropic truncation
Reply-To: PHENIX user mailing list <phenixbb at phenix-online.org<mailto:phenixbb at phenix-online.org>>

Hi Kendall,

This could work.  You could define a fixed set of test reflections, and never touch these, and never include them in refinement, and always use this fixed set to calculate a free R.  Then you could do whatever you want, throw away some work reflections, etc, refine, and evaluate how things are working with the fixed free R set.

All the best,
Tom T

________________________________________
From: phenixbb-bounces at phenix-online.org<mailto:phenixbb-bounces at phenix-online.org> [phenixbb-bounces at phenix-online.org<mailto:phenixbb-bounces at phenix-online.org>] on behalf of Kendall Nettles [knettles at scripps.edu<mailto:knettles at scripps.edu>]
Sent: Thursday, May 03, 2012 7:05 AM
To: PHENIX user mailing list
Subject: Re: [phenixbb] Geometry Restraints - Anisotropic truncation

Hi Pavel,
Could you use a similar approach to figuring out where to cut your data in general? Could you compare the effects of throwing out reflections in different bins, based on I/sigma, for example, and use this to determine what is truly noise? I might predict that as you throw out "noise" reflections you will see a larger drop in Rfree than from throwing out "signal" reflections, which should converge as you approach the "true" resolution. While we don't use I/sigma exclusively, we do to tend towards cutting most of our data sets at the same i/sigma, around 1.5. It would be great if there was a more scientific approach.
Best,
Kendall

On May 3, 2012, at 7:45 AM, Pavel Afonine wrote:

Hi Kendall,

removing same amount of data randomly gives Rwork/Rfree ~ 30/35%.

Pavel

On 5/3/12 4:13 AM, Kendall Nettles wrote:
Hi Pavel,
What happens if you throw out that many reflections that have signal? Can you take out a random set of the same size?
Best,
Kendall

On May 3, 2012, at 2:41 AM, "Pavel Afonine"<pafonine at lbl.gov<mailto:pafonine at lbl.gov>>  wrote:

Hi Kendall,

I just did this quick test: calculated R-factors using original and
anisotropy-corrected Mike Sawaya's data (*)

Original:
   r_work : 0.3026
   r_free : 0.3591
   number of reflections: 26944

Truncated:
   r_work : 0.2640
   r_free : 0.3178
   number of reflections: 18176

The difference in R-factors is not too surprising given how many
reflections was removed (about 33%).

Pavel

(*) Note, the data available in PDB is anisotropy corrected. The
original data set was kindly provided to me by the author.

On 5/2/12 5:25 AM, Kendall Nettles wrote:
I didnt think the structure was publishable with Rfree of 33%  because I was expecting the reviewers to complain.

We have tested a number of data sets on the UCLA server and it usually doesn't make much difference. I wouldn't expect truncation alone to change Rfree by 5%, and it usually doesn't. The two times I have seen dramatic impacts on the maps ( and Rfree ), the highly anisotrophic sets showed strong waves of difference density as well, which was fixed by throwing out the noise. We have moved to using loose data cutoffs for most structures, but I do think anisotropic truncation can be helpful in rare cases.

Kendall

On May 1, 2012, at 3:07 PM, "Dale Tronrud"<det102 at uoxray.uoregon.edu<mailto:det102 at uoxray.uoregon.edu>>   wrote:

  While philosophically I see no difference between a spherical resolution
cutoff and an elliptical one, a drop in the free R can't be the justification
for the switch.  A model cannot be made more "publishable" simply by discarding
data.

  We have a whole bunch of empirical guides for judging the quality of this
and that in our field.  We determine the resolution limit of a data set (and
imposing a "limit" is another empirical choice made) based on Rmrg, or Rmes,
or Rpim getting too big or I/sigI getting too small and there is no agreement
on how "too big/small" is too "too big/small".

  We then have other empirical guides for judging the quality of the models
we produce (e.g. Rwork, Rfree, rmsds of various sorts).  Most people seem to
recognize that the these criteria need to be applied differently for different
resolutions. A lower resolution model is allowed a higher Rfree, for example.

  Isn't is also true that a model refined to data with a cutoff of I/sigI of
1 would be expected to have a free R higher than a model refined to data with
a cutoff of 2?  Surely we cannot say that the decrease in free R that results
from changing the cutoff criteria from 1 to 2 reflects an improved model.  It
is the same model after all.

  Sometimes this shifting application of empirical criteria enhances the
adoption of new technology.  Certainly the TLS parametrization of atomic
motion has been widely accepted because it results in lower working and free
Rs.  I've seen it knock 3 to 5 percent off, and while that certainly means
that the model fits the data better, I'm not sure that the quality of the
hydrogen bond distances, van der Waals distances, or maps are any better.
The latter details are what I really look for in a model.

  On the other hand, there has been good evidence through the years that
there is useful information in the data beyond an I/sigI of 2 or an
Rmeas>   100% but getting people to use this data has been a hard slog.  The
reason for this reluctance is that the R values of the resulting models
are higher.  Of course they are higher!  That does not mean the models
are of poorer quality, only that data with lower signal/noise has been
used that was discarded in the models you used to develop your "gut feeling"
for the meaning of R.

  When you change your criteria for selecting data you have to discard
your old notions about the acceptable values of empirical quality measures.
You either have to normalize your measure, as Phil Jeffrey recommends, by
ensuring that you calculate your R's with the same reflections, or by
making objective measures of map quality.

Dale Tronrud

P.S. It is entirely possible that refining a model to a very optimistic
resolution cutoff and calculating the map to a lower resolution might be
better than throwing out the data altogether.

On 5/1/2012 10:34 AM, Kendall Nettles wrote:
I have seen dramatic improvements in maps and behavior during refinement following use of the UCLA anisotropy server in two different cases. For one of them the Rfree went from 33% to 28%. I don't think it would have been publishable otherwise.
Kendall

On May 1, 2012, at 11:10 AM, Bryan Lepore wrote:

On Mon, Apr 30, 2012 at 4:22 AM, Phil Evans<pre at mrc-lmb.cam.ac.uk<mailto:pre at mrc-lmb.cam.ac.uk>>    wrote:
Are anisotropic cutoff desirable?
is there a peer-reviewed publication - perhaps from Acta
Crystallographica - which describes precisely why scaling or
refinement programs are inadequate to ameliorate the problem of
anisotropy, and argues why the method applied in Strong, et. al. 2006
satisfies this need?

-Bryan
_______________________________________________
phenixbb mailing list
phenixbb at phenix-online.org<mailto:phenixbb at phenix-online.org>
http://phenix-online.org/mailman/listinfo/phenixbb
_______________________________________________
phenixbb mailing list
phenixbb at phenix-online.org<mailto:phenixbb at phenix-online.org>
http://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________
phenixbb mailing list
phenixbb at phenix-online.org<mailto:phenixbb at phenix-online.org>
http://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________
phenixbb mailing list
phenixbb at phenix-online.org<mailto:phenixbb at phenix-online.org>
http://phenix-online.org/mailman/listinfo/phenixbb
_______________________________________________
phenixbb mailing list
phenixbb at phenix-online.org<mailto:phenixbb at phenix-online.org>
http://phenix-online.org/mailman/listinfo/phenixbb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/phenixbb/attachments/20120503/4b818d3e/attachment.htm>