Agree although i usually look to CC1/2. Rmeas makes more sense than Rmerge but- most software reports both, so cant you just provide Rmeas yourself Probably simpler to persuade journals to alter the Table 1 requirements than get all developers to comment those lines out!
Eleanor On 4 July 2017 at 22:09, Keller, Jacob <kell...@janelia.hhmi.org> wrote: > I suggested replacing Rmerge/sym/cryst with Rmeas, not Rpim. Rmeas is > simply (Rmerge * sqrt(n/n-1)) where n is the number of measurements of that > reflection. It's merely a way of correcting for the multiplicity-related > artifact of Rmerge, which is becoming even more of a problem with data sets > of increasing variability in multiplicity. Consider the case of comparing a > data set with a multiplicity of 2 versus one of 100: equivalent data > quality would yield Rmerges diverging by a factor of ~1.4. But this has all > been covered before in several papers. It can be and is reported in > resolution bins, so can used exactly as you say. So, why not "disappear" > Rmerge from the software? > > The only reason I could come up with for keeping it is historical reasons > or comparisons to previous datasets, but anyway those comparisons would be > confounded by variabities in multiplicity and a hundred other things, so > come on, developers, just comment it out! > > JPK > > > > > -----Original Message----- > From: graeme.win...@diamond.ac.uk [mailto:graeme.win...@diamond.ac.uk] > Sent: Tuesday, July 04, 2017 4:37 PM > To: Keller, Jacob <kell...@janelia.hhmi.org> > Cc: ccp4bb@jiscmail.ac.uk > Subject: Re: [ccp4bb] Rmergicide Through Programming > > HI Jacob > > Unbiased estimate of the true unmerged I/sig(I) of your data (I find this > particularly useful at low resolution) i.e. if your inner shell Rmerge is > 10% your data agree very poorly; if 2% says your data agree very well > provided you have sensible multiplicity… obviously depends on sensible > interpretation. Rpim hides this (though tells you more about the quality of > average measurement) > > Essentially, for I/sig(I) you can (by and large) adjust your sig(I) values > however you like if you were so inclined. You can only adjust Rmerge by > excluding measurements. > > I would therefore defend that - amongst the other stats you enumerate > below - it still has a place > > Cheers Graeme > > > On 4 Jul 2017, at 14:10, Keller, Jacob <kell...@janelia.hhmi.org> wrote: > > > >> Rmerge does contain information which complements the others. > > > > What information? I was trying to think of a counterargument to what I > proposed, but could not think of a reason in the world to keep reporting it. > > > > JPK > > > > > > On 4 Jul 2017, at 12:00, Keller, Jacob <kell...@janelia.hhmi.org<mailto: > kell...@janelia.hhmi.org>> wrote: > > > > Dear Crystallographers, > > > > Having been repeatedly chagrinned about the continued use and reporting > of Rmerge rather than Rmeas or similar, I thought of a potential way to > promote the change: what if merging programs would completely omit > Rmerge/cryst/sym? Is there some reason to continue to report these stats, > or are they just grandfathered into the software? I doubt that any journal > or crystallographer would insist on reporting Rmerge per se. So, I wonder > what developers would think about commenting out a few lines of their code, > seeing what happens? Maybe a comment to the effect of "Rmerge is now > deprecated; use Rmeas" would be useful as well. Would something > catastrophic happen? > > > > All the best, > > > > Jacob Keller > > > > ******************************************* > > Jacob Pearson Keller, PhD > > Research Scientist > > HHMI Janelia Research Campus / Looger lab > > Phone: (571)209-4000 x3159 > > Email: kell...@janelia.hhmi.org<mailto:kell...@janelia.hhmi.org> > > ******************************************* > > > > > > -- > > 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 > > > >
