I suppose observations from the same unmerged hkl (also known as a "relp") are independent in some ways, but not in others. For example, partials of the same relp are independent with respect to photon-counting noise, detector read-out noise, flicker in the source, and most types of shutter jitter and sample vibration, but not independent when it comes to other kinds of error, like detector pixel calibration and "absorption errors". Depending on which of these sources of error dominates, a given pair of observations may or may not be independent. With CuKa radiation, "absorption errors" usually dominate, so I suppose it does make sense to treat partials of the same relp as non-independent observations. However, I think it is important that at ~1 A, absorption errors are much smaller. Perhaps a better name for "absorption errors" is "differential attenuation", since they arise not from absorption itself, but rather the difference in Beer's-law attenuation along two different paths taken by the x-rays through the crystal and out to two different spots. For example, an extra 100 um of water or protein along one path vs another will create a 10% difference in spot intensities with a CuKa radiation, but less than 3% with 1 A x-rays. Scaling programs attempt to correct for this, but depending on how "crazy" the crystal/drop/loop/etc. shape is, they may or may not be able to do it perfectly. It is also hard to calibrate a detector to better than a few percent, but that is a very long story.
Of course, errors of a few percent will never be important for refinement, where the model-data systematic error (Rcryst/Rfree > 15%) dominates. But for anomalous differences a few percent is the magnitude of the signal you are trying to measure! So, it can be easy to convince SCALA (and indeed oneself) that you are getting good signal-to-noise (DANO/SIGDANO), even if you're not. This is especially true if you measure the same phi range over and over again. For example, if you average n=100 "observations", each with sigma = 1.0, then you usually assign a sigma to the average value that is 1/sqrt(n) smaller, or 0.1. This is why the signal to noise ratio improves with averaging. Or, at least, we think it does. If the "error" in all 100 observations is a systematic shift in the same direction, then the true "error" of the average is not 0.1, but actually closer to 1.0. My point is, "multiplicity" is not the whole story. It really comes down to the sigmas and how realistic they actually are. You never know, the extra measurements in your high-multiplicity dataset might really be "redundant". -James Holton MAD Scientist On Fri, Jul 15, 2011 at 11:37 AM, Phil Evans <p...@mrc-lmb.cam.ac.uk> wrote: > Summed partials count as one. SCALA doesn't adjust for <360deg, maybe it > should as they are not independent. What would you call them? > > I prefer "multiplicity" since Elspeth Garman commented "if they are > redundant why bother measuring them" > > Phil > > Sent from my iPhone > > On 15 Jul 2011, at 18:24, James Holton <jmhol...@lbl.gov> wrote: > >> >> At the risk of asking a question to which I should already know the answer: >> >> do partials "count" as "redundancy"? >> >> That is, in SCALA, is the number of "observations" the number of recorded >> spots? Or is it the number of recorded spots after adding partials? If it >> is the latter, what happens if you collect more than 360 degrees of data? >> Does the second pass through a given unmerged hkl index count as "more >> partials" or is it now somehow upgraded to an "independent" observation? >> >> Then again, in Eastern English the word "redundancy" has a negative >> connotation, and the output of SCALA actually uses the word "multiplicity". >> I wonder if that makes unmerged partials "redundant"? >> >> -James Holton >> MAD Scientist >> >> On 7/15/2011 8:09 AM, Ed Pozharski wrote: >>> On Fri, 2011-07-15 at 09:26 +0100, Phil Evans wrote: >>>> Ed. You could count them from the unmerged output as you say, or I >>>> could make you a special version of SCALA or Aimless maybe next week >>>> >>> Phil, >>> >>> that would be fantastic! Hope there is broader interest in such option >>> (beyond Robbie and myself). I'll try unmerged output in the meantime. >>> >>> Ed. >>> >> >
