HI Ed

Rmerge is probably the number which would tell a reader that the experimenter adopted a very sensible high redundancy / low dose protocol - just reporting Rpim etc. hides this though tells you other things, which could change the interpretation of the data.

I have data with Rmerge > 1000% in the outer shell, yet I am happy to defend it as "true" and yes this is high redundancy low dose data.

Cheerio Graeme

-----Original Message-----
From: CCP4 bulletin board [mailto:[log in to unmask]] On Behalf Of Edward A. Berry
Sent: 16 November 2015 04:07
To: ccp4bb
Subject: Re: [ccp4bb] NSMB Still Has Rmerge?

I had the impression from the original post (but I may be wrong) that the problem was rmerge being present in the template supplied by the journal, i.e. something they expect everyone to report.

This is of special concern with respect to recently discussed trends in data collection with zero-background detectors. It may be the case that only the total photons is important, but I expect it is the photons per frame that determines Rmerge. If one collects high redundancy low-dose data the Rmerge should go through the (conventional reviewer's) roof. Not because of high redundancy, which contributes at most a factor of sqr(2) and makes the estimate more correct anyway, but because of the low dose per frame. Scalepack users will then look at chi^2 and say yes, 0.25 seems pretty high for Rmerge in the lowest shell, but chi^2 is right around 1 in every shell, so the high Rmerge is due to "weak data" and not wrong space group or beamline problems.  But Rpim shows the final merged data is not weak.
eab

On 11/15/2015 01:14 PM, Quyen Hoang wrote:
> I think that we all aware of the issues and debates about Rmerge and the newer measures. But the issue here, to me, is that whether or not one can be justified to dictate what others do with their own data and how they wish to analyze them. If the Rmerge was wrongly used to support a certain conclusion, then sure it should be criticized. But if it was used as a simple statistic to estimate data merging consistency and there is no indication of that affecting the quality of the final model, who would have the right to demand alternative measures instead?
>
> Quyen
>
> Sent from my BlackBerry 10 smartphone.
>    Original Message
> From: Keller, Jacob
> Sent: Sunday, November 15, 2015 12:40 PM
> To: [log in to unmask]
> Reply To: Keller, Jacob
> Subject: Re: [ccp4bb] NSMB Still Has Rmerge?
>
> But folks, Rmerge can be downright deceptive: imagine a paper in which two related structures are mentioned: one with a multiplicity of 7, one with 17. Rmerge could be 5% for the first, and 20% for the second, but the second one might be better. Or perhaps not. What if the resolutions or spacegroups are different? So...how does one compare them? And why not just switch Rmerge to Rmeas? It's frustrating because many have tried to think of ways to improve on Rmerge, with some success, and this sort of nullifies that work.
>
> But these arguments are all already in the literature, most
> prominently discussed in
> https://www.sciencemag.org/content/336/6084/1030.abstract
>
> JPK
>
> -----Original Message-----
> From: CCP4 bulletin board [mailto:[log in to unmask]] On Behalf Of
> Bert Van-Den-Berg
> Sent: Sunday, November 15, 2015 11:45 AM
> To: [log in to unmask]
> Subject: Re: [ccp4bb] NSMB Still Has Rmerge?
>
> In principle it is indeed not a problem, but in practice one still
> risks negativity from (ignorant or stubborn) reviewers when reporting
> R merge values > 100%
>
> bert
>
> ________________________________________
> From: CCP4 bulletin board <[log in to unmask]> on behalf of Quyen
> Hoang <[log in to unmask]>
> Sent: 15 November 2015 13:47
> To: [log in to unmask]
> Subject: Re: [ccp4bb] NSMB Still Has Rmerge?
>
> I also don't see a problem with reporting R-merge.
>
> Quyen
>
> Sent from my BlackBerry 10 smartphone.
> Original Message
> From: Ed Pozharski
> Sent: Saturday, November 14, 2015 2:46 PM
> To: [log in to unmask]
> Reply To: Ed Pozharski
> Subject: Re: [ccp4bb] NSMB Still Has Rmerge?
>
> No objection here.
>
> On 11/13/2015 05:04 PM, Tim Gruene wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Ed,
>>
>> even better to make unmerged data a deposition requirement.
>>
>> Best,
>> Tim
>>
>> On Friday, November 13, 2015 02:07:22 PM Ed Pozharski wrote:
>>> There is nothing wrong with reporting Rmerge per se. The best place
>>> to address this is probably PDB - if CC1/2, for example, becomes a
>>> deposition requirement, you can always track it down whether it's
>>> included in the paper or not. Standardizing "Table 1" across journal
>>> universe would be impractical.
>>>
>>>
>>> Sent from a mobile device
>> - --
>> - --
>> Paul Scherrer Institut
>> Tim Gruene
>> - - persoenlich -
>> OFLC/102
>> CH-5232 Villigen PSI
>> phone: +41 (0)56 310 5754
>>
>> GPG Key ID = A46BEE1A
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iD8DBQFWRl5uUxlJ7aRr7hoRAq1qAKDJQ9D7mRmWz/q3swX3K3SSdbwjPgCgyTbW
>> 1rRT+q/nZKfo1MVUM1q9+08=
>> =uEri
>> -----END PGP SIGNATURE-----
>>
>

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom