Hi
I'd be somewhat surprised if this accounted for the difference since
it would require the routine collection of many overloads in each
dataset before you'd notice that the completion was higher
systematically.
(The two different cutoffs that James refers to are the absolute
cutoff (where reflections aren't integrated) and the profile-fitting
cutoff (which is used if you want to profile fit overloads).)
Since we've had automatic detector recognition since 2002, and have
deprecated the use of the DETECTOR (or SCANNER) keyword unless you
have an unusual set-up since then, most people should never come
across this as a problem even if they write their own scripts. James
does make a good point though - if you use the "DETECTOR TYPE"
keywords, you also need to provide other keywords to make sure the
processing proceeds according to expectations!
I think you'd need more information on where the "extra" reflections
are, or if they are strong/weak/etc as Phil suggested, before
pointing the finger in any particular direction.
I replied to Simon yesterday privately with the following -
I seem to remember something like this when we started looking at
Pilatus images a few years ago, but I didn't do the processing
myself so can't be sure about it.
In principle, if the rejection and acceptance criteria are the
same, then the two programs (and d*Trek and HKL...) should report
the same completeness and the same overall stats, once you take
into account the different ways the various merging Rs are
calculated. I'm always pleased when people give Mosflm a good
report, but I don't think there's a huge difference in the data
coming out of the different programs. Occasionally, we do find a
dataset where one program is better than the others (I put this
down to the particular dataset being similar to one that the
developer used).
However, from memory I think XDS has rather stricter rejection
criteria by default - and this gives lower completeness,
multiplicity and merging Rs (if you merge fewer "bad" equivalents
you get lower R factors). When we ran tests using Mosflm to reject
similarly "bad" reflections from a high quality dataset, we got
similar completeness and merging Rs - but this is entirely artificial.
I *think* it comes down to whichever program you're most used to
running, and the one you know how to get the best out of. I'm sure
that you will get replies from people saying that XDS (or whatever
program) always gives higher completeness etc than Mosflm!
On 9 Jun 2010, at 07:57, James Holton wrote:
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
Harry
--
Dr Harry Powell,
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge,
CB2 0QH
