In an ideal world, scaling and merging would be fully automated and fool-proof. Perhaps
it is a consequence of using a combination of programs from different sources, but the
naive way of dealing with kappaCCD data will lead to either reflections being rejected
(by Scalepack) or to inclusion of overloaded (i.e. worse-than-useless)
data (by SADABS). While it would be possible to write a program to compare the
'fast' and 'slow' scan '.hkl' files, calculate scaling parameters etc. it is always
instructive to delve into the problem to ensure that no spurious data are included.
The process described here requires a bit of work to identify the outliers, but it
We will use refinement diagnostics from an actual structure refinement run against the
'slow' data set to identify the problem reflections (in the slow-scan set). This
means that you need to solve your structure, clean it up (assign atom types etc.),
and run a few rounds of refinement with unmerged data (the model does not have to be
'finished', but it does have to be 'right'). This is just part of what you would do in
any case, even if you weren't trying to get an optimally merged dataset, so even though
it sounds like a lot of extra work, it really isn't.
In any case, once you are at a suitable state of refinement [with SHELXL using
MERG 0 in the '.ins'/'.res' files of course!], you need to open the last SHELXL
'.lst' file and scroll down to the list of "Most Disagreeable Reflections". In the
example here it looks like this:
What to make of this ? The top eight reflections have Fo^2 << Fc^2. Notice also
that these are all at very or fairly low resolution (high numbers in the last column
equal low resolution - it's a reciprocal thing!). These eight are candidates for
being overloaded intensties. The (-1 0 0) data points could feasibly be partially
obscured by the beamstop, but even 7.52Å is not quite low enough resolution
for that on our kappaCCD. One might naively think that overloads would show up as
maxed out numbers, but that is not the case. Perhaps it has to do with how the
detector copes with too-high x-ray flux, coupled with how Denzo handles the
confusion. Who knows ? It matters not, because it is fixable.
We can use the 'fast' scan to check if these sets of indices show up as "disgreeable"
when the model is refined against the 'fast' dataset. This is of course a valuable
check, and will also tell us whether (-1 0 0) was hidden by the beamstop. In the
present case there are no such "disagreeables" with the 'fast' set, and a quick check
of the 'fast' '.hkl' file shows that there are reflections (or symmetry equivalents)
available to fill the gaps when we eliminate these reflections from the 'slow' set.
The above window shows the 'slow' '.hkl' file opened in a text editor. The cursor is
poised to remove the (-1 0 0) entries. Go ahead and cut out these and the other
"disagreeables" from the 'slow' scan '.hkl' file, and save the result. (For the sake of
good book-keeping it is wise to keep a copy of the unedited 'slow' files, but if they
are ever needed they can easily be reproduced from the frames). Disk space
is so cheap nowadays that there is never any reason to erase data!
We now have the files ('fast' and edited 'slow' '.hkl') ready for merging in
XPREP. Go on to the last part of this tutorial (part 6).