Re: [ccp4bb]: Summary of Replies: Data Reduction for mosaic crystals...

[Anastassis Perrakis <perrakis@nki.nl>]

> If you DO have crystals with 2.0deg mosaicity:
> 1. Am I alone thinking Raji did *not 'have had'* to take 0.1deg frames ?
>     Besides the good ideas offered for really processing the data,
>     does fine phi slicing improve anything for *very mosaic* crystals ?

You're not alone. I _assumed_ that he had a large cell and was doing his
best to avoid overlaps by having a very small oscillation angle. However,
as the problem was stated, i.e. he has a mosaicity of ~2 and _hence_ had
to have a small oscillation angle, I can't back up this assumption (in
the absence of other information)!

And, although I am a spoiled user of 'Strategy/Mosflm' I am tempted to
summarise
what Pierre and Harry explained with a simple-minded formula:

If (use pocket calculator)

Mosaicity >~ arctan(Res/EMPCA)

where:
Res = Maximum Resolution
EMPCA = Effective_Maximum_Primitive_Cell_Axis ;-)
ie The primitive axis that will get to line up with the beam during data collection
(i.e.in a C-lattice that's the diagonal!)

Then the spots do physically overlap in reciprocal space and there's little or no point
trying to avoid overlap by varying the data collection geometry ...
(that partially answers Ed's 'second asrgument')

> I was a little disappointed (from my partisan point-of-view!!) that Raji
> didn't include the Mosflm/Scala option in his summary, especially as this
> is the CCP4 BB...
I have to say that as far as I recall mosflm was not able to handle these
cases till recently
If mos > osc_angle /2 it would stop with an error message - NOT crash
;-)
So people might be relucant to use it ....BUT:

It *DOES* work fine now (ccp4 4.2 version and higher) and it does a very good job.
We had one xtal on which we collected fine phi slicing (0.1) and mos. was ~0.7
(yes, that was bad data collection strategy) and 'new' mosflm did great.
So did denzo/scalepack *after* fixing the mosaicity in scalepack (like Ed describes).

    Tassos