[phenixbb] Geometry Restraints - Anisotropic truncation

Pavel Afonine pafonine at lbl.gov
Thu May 3 04:45:47 PDT 2012


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>  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>   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>    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
>> http://phenix-online.org/mailman/listinfo/phenixbb
> _______________________________________________
> phenixbb mailing list
> phenixbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/phenixbb



More information about the phenixbb mailing list