JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for CCP4BB Archives


CCP4BB Archives

CCP4BB Archives


CCP4BB@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CCP4BB Home

CCP4BB Home

CCP4BB  June 2012

CCP4BB June 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: @Ian:Death of Rmerge

From:

aaleshin <[log in to unmask]>

Reply-To:

aaleshin <[log in to unmask]>

Date:

Sun, 3 Jun 2012 23:00:50 -0700

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (123 lines)

Wow, it is quite a lecture here! It is very appreciated.

I admit some (most?) of my statements were questionable. Thus, I did not know how sigI would be calculated in case of multiple observations, and, indeed, its proper handling should make <sigI/I> similar to Rmerge. Consequently,  <I/sigI> substitutes Rmerge fairly well. 

Now, where the metric Rmerge=0.5 came from? If I remember correctly, It was proposed here at ccp4bb. Also, one reviewer suggested to use it. I admit that this is quite an arbitrary value, but when everyone follows it, structures become comparable by this metric. If there is a better approach to estimate the resolution, lets use it, but the common rule should be enforced, otherwise the resolution becomes another venue for cheating. 

Once again, I was talking about metric for the resolution, it does not need to be equal to metric for the data cutoff. 

Alex



On Jun 3, 2012, at 2:55 PM, Ian Tickle wrote:

> Hi Alex
> 
> On 3 June 2012 07:00, aaleshin <[log in to unmask]> wrote:
>> I was also taught that under "normal conditions" this would occur when the data are collected up to the shell, in which Rmerge = 0.5.
> 
> Do you have a reference for that?  I have not seen a demonstration of
> such an exact relationship between Rmerge and resolution, even for
> 'normal' data, and I don't think everyone uses 0.5 as the cut-off
> anyway (e.g. some people use 0.4, some 0.8 etc - though I agree with
> Phil that we shouldn't get too hung up about the exact number!).
> Certainly having used the other suggested criteria for resolution
> cut-off (I/sigma(I) & CC(1/2)), the corresponding Rmerge (and Rpim
> etc) seems to vary a lot (or maybe my data weren't 'normal').
> 
>> One can collect more data (up to Rmerge=1.0 or even 100) but the resolution of the electron density map will not change significantly.
> 
> I think we are all at least agreed that beyond some resolution
> cut-off, adding further higher resolution 'data' will not result in
> any further improvement in the map (because the weights will become
> negligible).  So it would appear prudent at least to err on the high
> resolution side!
> 
>> I solved several structures of my own, and this simple rule worked every time.
> 
> In what sense do you mean it 'worked'?  Do you mean you tried
> different cut-offs in Rmerge (e.g. 0.25, 0.50, 0.75, 1.00 ...) and
> then used some metric to judge when there was no further significant
> change in the map and you noted that the optimal value of your chosen
> metric always occurs around Rmerge 0.5?; and if so how did you judge a
> 'significant change'?  Personally I go along with Dale's suggestion to
> use the optical resolution of the map to judge when no further
> improvement occurs.  This would need to be done with the completely
> refined structure because presumably optical resolution will be
> reduced by phase errors.  Note that it wouldn't be necessary to
> actually quote the optical resolution in place of the X-ray resolution
> (that would confuse everyone!), you just need to know the value of the
> X-ray resolution cut-off where the optical resolution no longer
> changes (it should be clear from a plot of X-ray vs. optical
> resolution).
> 
>> I is measured as a number of detector counts in the reflection minus background counts.
>> sigI is measured as sq. root of I plus standard deviation (SD) for the background plus various deviations from ideal experiment (like noise from satellite crystals).
> 
> The most important contribution to the sigma(I)'s, except maybe for
> the weak reflections, actually comes from differences between the
> intensities of equivalent reflections, due to variations in absorption
> and illuminated volume, and other errors in image scale factors
> (though these are all highly correlated).  These are of course exactly
> the same differences that contribute to Rmerge.  E.g. in Scala the
> SDFAC & SDADD parameters are automatically adjusted to fit the
> observed QQ plot to the expected one, in order to account for such
> differences.
> 
>> Obviously, sigI cannot be measured accurately. Moreover, the 'resolution' is related to errors in the structural factors, which are  average from several measurements.
>> Errors in their scaling would affect the 'resolution', and <I/sigI> does not detect them, but Rmerge does!
> 
> Sorry you've lost me here, I don't see why <I/sigI> should not detect
> scaling errors: as indicated above if there are errors in the scale
> factors this will inflate the sigma(I) values via increased SDFAC
> and/or SDADD, which will increase the sigma(I) values which will in
> turn reduce the <I/sigma(I)> values exactly as expected.  I see no
> difference in the behaviour of Rmerge and <I/sigma(I)> (or indeed in
> CC(1/2)) in this respect, since they all depend on the differences
> between equivalents.
> 
>> Rmerge, it means that the symmetry related reflections did not merge well. Under those conditions, Rmerge becomes a much better criterion for estimation of the 'resolution'  than <sigi/I>.
> 
> As indicated above, if the symmetry equivalents don't merge well it
> will increase the sigma(I)'s and reduce <I/sigma(I)>, so in this
> respect I don't see why Rmerge should be any better than <I/sigma(I)>.
> My biggest objection to Rmerge (and this applies also to CC(1/2)) is
> that it involves throwing away valuable information, namely the
> measured sigma(I) values from counting stats.  This is not usually a
> good idea (in statistical parlance it reduces the 'power' of the test)
> - and it's not as though one can argue the sigma's are so small that
> they can be neglected (at least not for the weak reflections).  Even
> though as you say the estimates of sigma(I) may not be very accurate,
> it seems to me that any estimate is better than no estimate.  In any
> case the estimates of sigma(I) are probably quite accurate for the
> weak reflections, it's just for the strong ones that the assumptions
> tend to break down.  However if we're estimating resolution from
> <I/sigma(I)> it's only the weak reflections in the outer shell that
> are relevant, so I don't think accuracy of sigma(I) is an issue.
> 
>> If someone decides to use <I/sigI> instead of Rmerge, fine, let it be 2.0.
> 
> As I indicated previously I think 2 is too high, it should be much
> closer to 1 (and again it would appear prudent to err on the side of
> the lower value), because in the outer shell the majority of
> I/sigma(I) values will be < 1 (just from the normal distribution of
> errors).  This means that in order to get an average value of
> I/sigma(I) = 2 you need a lot of very significant intensities >> 3.
> The fallacy here lies in comparing the average I/sigma(I) with the
> standard '3 sigma' criterion which is actually appropriate only for a
> single intensity.  Of course data anisotropy may well "throw a spanner
> in the works".
> 
>> Alternatively, the resolution could be estimated from the electron density maps.
> 
> I agree, using the optical resolution in the manner indicated above,
> but still quoting the corresponding X-ray resolution for backwards
> compatibility!
> 
>> I hope everyone agrees that the resolution should not be dead..
> 
> I completely agree: I say "Long live the resolution!" (sorry I
> couldn't resist it).
> 
> -- Ian

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager