Check your mosflm input file.
If this is an "ADSC" type detector and you have specified that it is
(using "DETECTOR TYPE ADSC" or "SCANNER TYPE ADSC"), but have not
explicitly specified the overload limit with "OVERLOAD CUTOFF", then the
default overload cutoff for integration will be 100,000, and this
effectively turns off overload detection. Note that there are TWO
different overload cutoffs in mosflm, but both are listed in the log
next to the string "(CUTOFF)".
I only discovered this myself a few weeks ago, and I have patched the
current Elves release:
http://bl831.als.lbl.gov/~jamesh/elves/download.html
to avoid this problem when they run mosflm, but versions from the last
two years may actually miss overloads!
-James Holton
MAD Scientist
Simon Kolstoe wrote:
Thanks Tim, Phil and Andrew for your answers.
Just one further related question:
Why is it that mosflm seems to report higher completeness than XDS on
the same data (I've seen this on about 50 datasets)? I always thought
it was due to mosflms peak extrapolation but it seems this isn't the
answer if SCALA throws those reflections out.
Thanks,
Simon
On 7 Jun 2010, at 15:35, Phil Evans wrote:
Mosflm integrates them (profile-fitted overloads) but flags them.
Pointless uses them for systematic absence tests. Scala by default
ignores them, but you can include them if you want: this is not
normally recommended since they are pretty inaccurate (look in the
"Excluded data" tab of ccp4i/Scala)
If you are merging strong & weak datasets it should do the right
thing, I think.
Phil
On 7 Jun 2010, at 15:09, Simon Kolstoe wrote:
Dear CCP4bb,
I was wondering if someone could tell me how mosflm and scala deal
with overloaded reflections. From my understanding mosflm
extrapolates the overloaded peaks but then scala throws them out
completely - is this right?
If so am I right to not worry about "contamination" from
extrapolated peaks when combining high and low resolution datasets
from the same crystal?
Thanks
Simon
