I see two questions here:
-Can we assume an unrealistically low mosaicity in order to reduce
overlaps.
-Is there any benefit in merging data from the same frames integrated with different strategy?

As for cheating on the mosaicity, which I  euphemistically call "peak sampling",
I think it can give usable data, at least for refinement if not for heavy atom
phasing, from data which is otherwise unusable. Think of the analogy of an HPLC
elution profile, where each compund coming through makes a peak on the strip-chart 
recorder at a particular position. The peaks may or may not be resolved with
baseline separation. Ideally, the amount of each compound is determined from
the integrated area under the peak, or some approximation like peak height
times width at half height. But if the peak has the same shape every time,
it could be quantitated by peak height alone, calibrating with a known standard.
Since the peak is the point where the signal from the desired compound is
greatest relative to that from the overlapping compounds, this may be the best
way (short of curve-fitting all the overlapping peaks) to quantitate
when peaks are badly overlapped.
   Now to make it more like diffraction data collection, suppose you don't have
a continuous readout but a fraction collector collecting fractions of
equal volume, and you read absorbance of each fraction after mixing to get
the average absorbance during that volume. If you have baseline separation
and the peak comes out in a single fraction (think "fully recorded") then
absorbance of that fraction gives the answer. If baseline separation but
the peak is spread across multiple fractions, you have to add up all
these "partials" to get the answer. If the peaks are badly overlapped,
you collect small fractions ("fine slicing") so that one near the peak
will approximate concentration at the peak, and use that peak absorbance.
   One problem, since the integrating program doesn't understand that
you want to sample the peaks, it will add partials when the peak comes
at the border between two frames. Say you have 2* mosaicity, collecting
0.5 degree frames, and telling the program the mosaicity is 0.5 degrees.
For most observations two partials will be added, but occasionally
the spot will be centered in one frame which will be taken as "full".
This can lead to up to 2x disagreement between different observations of
the same reflection, but after averaging several observations it won't
be that bad. Better to collect .25* frames, then either 2 or 3 frames
will be averaged for each measurement. Expect Rsym on the order of 12-15%
instead of 4-5%, but after refinement Rfree not much higher than
0.1 x resolution; and decent maps. Not good for sulfur SAD phasing, though.

Michael Rossmann described some program for resolving overlapped spots
(in each single frame?) by 2-D curve fitting. It doesn't seem to have
been adopted, maybe wasn't that successful. I hope 3D profile fitting
is something like this with the third dimension (frame to frame) included.
My fraction collector analogy refers to the third dimension, but most
of the spots that are overlapping in 2D (on a single frame) will also
be somewhat separated in the third dimension (otherwise cheating on
mosaicity wouldn't help) so their effect can be minimized by peak
sampling.

As for merging multiple strategies, probably won't help completeness,
because other datasets would be subsets of the one assuming lowest
mosaicity, but may help accuracy for those whose spots could be
integrated without resorting to cheating on the mosaicity

Ed

José Trincão wrote:
> Hello all,
> I have been trying to squeeze the most out of a bad data set (P1, anisotropic, crystals not reproducible). I had very incomplete data due to high mosaicity and lots of overlaps. The completeness was about 80% overall to ~3A. Yesterday I noticed that I could process the data much better fixing the mosaicity to 0.5 in imosflm. I got about 95% complete up to 2.5A but with a multiplicity of 1.7. I tried to integrate the same data fixing the mosaicity at different values ranging from 0.2 to 0.6 and saw the trend in completeness, Rmerge and multiplicity.
> Now, is there any reason why I should not just merge all these together and feed them to scala in order to increase multiplicity?
> Am I missing something?
>
> Thanks for any comments!
>
> Jose
>
>
> José Trincão, PhD	CQFB@FCT-UNL
> 2829-516 Caparica, Portugal
>
> "It's very hard to make predictions... especially about the future" - Niels Bohr
>