Re: [ccp4bb]: scalepack and unit cell questions

[Edward Berry <eaberry@lbl.gov>]

***  For details on how to be removed from this list visit the  ***
***          CCP4 home page http://www.ccp4.ac.uk         ***



cveldkam@post.its.mcw.edu wrote:
> Hi,
> I am rotation student and am very new to this so forgive my ignorence. I am
> having trouble with scalepack changing my unit cell dimentions and angles. I
> processed my data in denzo using p2 space group and get 88.19 212.21 125.94
> 90.00  91.21  90.00 as the unit cell in the .x files. I believe my lattice
> is primitive monoclinic and space group is p2 or p21 (not primitive
> orthorhombic and p222 or higher) because of the symmetry I see when using
> hklview. Every time I try to process my denzo output in scalepack using the
> p2 spacegroup my unit cell is changed to 212.21 125.94 88.19 90.00 90.00
> 90.00 in the header of the .sca file.

The choice of cell parameters written to the .sca header has changed in 
recent versions, so it may be important to know which version of scalepack 
you are using.

Until recently, the parameters used internally and output to the header
were those taken from the very first .x file read by scalepack. 
Post-refinement is performed and values of (e.g. mosaicity) from 
post-refinement are used to determine from how many frames partials
are added for each spot. However according to the denzo manual,

	"the postrefined value of the unit cell constants is not used 
	nor is it output in the Scalepack output file. You must get this 
	information from the log file if you are interested in it."

To see if scalepack is following this behavior, find out which .x file 
is read first and grep it for "cell". While you're at it, grep "cell" *.x ,
to see if it changed along the way. Could it be you processed the
first frame as orthorhombic and forgot to go back and redo it after 
deciding the crystal was monoclinic?

In the most recent version we downloaded (1.97.2) scalepack seems to be
putting the postrefined cell parameters in the output file (definitely an
improvement in my opinion). To see if scalepack is following this behavior,
redirect the output to a log file (if you haven't already) and find the
postrefined values. Postrefinement is the second set of iterations. 
In earlier versions it printed all the parameters for every frame at 
every iteration. Now by default(?) it prints only after the last iteration,
and if all parameters are fitted "fit crystal" rather than "fit batch"
it only prints a single line, so it is easy to overlook:

 Film #       a       b       c   alpha    beta   gamma    crysz   . . .
      2 129.121 169.809 231.803  90.000  90.000  90.000    7.777   . . .

If this value is the same as in your .sca header maybe the cell
really is orthorhombic and your data is accurate enough to define
the angles to 5 place accuracy! (Although I have never known scalepack
to reindex abc like that without using the "hkl matix" option.)
In fact you should confirm the asymmetry you see in hklview by 
scalepacking in P222 - should give R-merge around 50% or higher. 

If scalepack is not following either of these behaviors and you don't
get an answer from the bulletin board, you might send the question to
the folks at hkl@hkl-xray.com. 

However in the meantime you can just ignore the value in the .sca header.
Run truncate specifying the post-refined cell (this was the way to go 
anyway as long as scalepack was reporting the value from the first frame)
and carry on with the ccp4 side of your project.

Good luck,
Ed