 |
 |
Dear Jacob, As you can notice towards few rows up in the data collection statistics table, the redundancy/multiplicity values are usually explicitly reported in the article, unless the redundancy/multiplicity values are quite low (say <2), the Rmerge value along with a good value of multiplicity holds good statistically as a decent parameter; as the numerator term (1/N-1 or N/N-1) in the Rpim/Rmeas expression comes from it, of course the Rmeas/Rpim, CC1/2 values are encouraged to report in the CCP4 bb and elsewhere biblically. regards Ashok Nayak PhD student MSB Div, CSIR-CDRI Lucknow, India On Mon, Nov 16, 2015 at 1:42 AM, Graeme Winter <[log in to unmask]> wrote: > 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 > --