Ed,
Did you tell scalepack not to add partials? It certainly shouldn't be
doing this when your oscillation ranges overlap - perhaps it is smart
enough to realize this is the situation, perhaps not.
Marian Szebenyi
MacCHESS
Ed Pozharski wrote:
Ed,
thanks - this is a great suggestion. Unfortunately, it's not the
problem - I had the "oscillation start 0.0 range 0.5 step 0.001"
statement in the denzo input file. Denzo runs fine and there is no
slippage issue. I tried turning off postrefinement and both batch and
crystal rotx refinement (batch is what I do generally), to no avail.
Ed.
On Mon, 2010-02-22 at 19:11 -0500, Edward A. Berry wrote:
Try grepping "crystal" your .x files (or whatever you called the
denzo output files). Also grep for "start".
By default denzo updates start-phi to the end
of the previous oscillation. Since 0,5 degree is within radius of
convergence, it re-refines crystal rotx to be compatible with this
assumption and the oscillation photograph, which means crystal rotx
will be moving backwards 0.5 degrees for each frame. Scalepack
in postrefinement sees this as a serious case of "slippage" and is
unable to postrefine a value of crystal rotx that is compatible with
all the frames.
It may be possible to turn of post-refinement with "POSTREFINE 0"
or some such.
Ed
Ed Pozharski wrote:
I want to process bunch of frames with extremely short step - i.e. these
are 0.5degree oscillations but crystal only rotates by 1 degree over
1000 frames (I would have kept it at the same orientation if Rigaku
control software would allow zero step). Denzo can process the frames
all right, but scalepack chokes on it saying "Floating Exception". I
don't have much experience with mosflm, and it failed also.
What I wonder is if this happens because both programs have some bug in
these unusual conditions or there is something fundamental that prevents
scaling such data?
Cheers,
Ed.
