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.
>>>
>
>
|