We would like to have some information about the output files *.x of Denzo .
Regular (film output file, Denzo _ip) imaging plate output format (i.e. the format you would you to read in in FORTRAN) is:
format (3i4,i2,2f8.0,f7.0,f6.0,f6.0,2f7.0,f6.0,f8.0)
h,k,l
Flag 0 - full 1 - partial
Intensity (F**2) by profile fitting
s of intensity (F**2)
c2 of profile fitting
Intensity (F**2) by profile summation
Cosine of incidence angle at detector
Predicted pixel position of spot centroid (slow, fast) directions
Lorentz, polarization, obliquity combined factor
Strength of averaged profile in arbitrary units
Alternative, (york output file, Denzo _york1) format is:
format (3i4,i2,2f8.0,f7.0,f6.0,f6.0,2f7.0,f6.0,f8.0)
h,k,l
Flag 0 - full 1 - partial
Intensity (F**2) by profile fitting
s of intensity (F**2)
c2 of profile fitting
Intensity (F**2) by profile summation
Cosine of incidence angle at detector
Predicted pixel position of spot centroid (slow, fast) directions
Lorentz, polarization, obliguity combined factor
Strength of averaged profile in arbitrary units
Partiality (fraction of the intensity of the reflection extected in this image)
Diffraction angle (degrees)
The last may be very useful when preparing input to program SCALA
Is the Denzo output file format dependent on the type of detector?
It is now the same.
Total number of reflections output from Denzo = 174715
unique reflections = 83873
reflections in reject.dat file = 1398
output from Scalepack = 73161
From this I think I've only rejected about 2% of data.
No, only 1398/174715, about 0.6%
Below is a bit of a *.x file from Denzo. Notice the middle reflection. The profile fitted intensity and thes are not fn.1 but seem to be integer data. Is this an intended part of the program to deal with overflows, or have I run into an operating system bug? Do you think this will only happen on reflections flagged with a negative s ?
2 -16 -28 1 134.8 191.2 1.37 25.3 0.995 1371.5 1284.9 0.191 3252.4
0 -12 -32 1 118141 5399 24.77-10031 0.997 1372.8 1196.3 0.191 3094.7
-8 6 -50 1 9095.4 9536.0 13.85 393.1 0.996 1372.2 805.2 0.192 5856.9
Yes, this an intended part of the program to deal with overflows.
The problem is that the Denzo .x file does not have information about the j angle of the individual reflection, I know it has information about the starting j , ending j of the batch but NOT the j of each and every reflection which is the ROT column used in the CCP4 package. This is the problem, although rotavata and agrovata do not need this info, scala does.
york output file has this information, see above.
Is it possible to suppress this function of putting information at the end of the .x file?
No, it is not possible. Current rotaprepa can skip this information.
On integration the output often has many reflections with negative s s - what have I done wrong?
Nothing or almost nothing, e.g. resolution limit too high for MAR scanner.
Could you tell me if the Denzo format has changed greatly? Rotaprep use to convert Denzo images to mtz images but it no longer works. I want to compare CCP4 processing to Scalepack processing. Just using the "lcf batch" or york output file does not do the trick.
Use current version of rotaprep (from ccp4) with york output file
I am still unable to go to Scala since the ROT information does not carry through rotaprep. So far though Scalepack does the same as rotavata and agrovata. Not surprising.
Check with Eleanor Dodson or Phil Evans.
Does Scalepack use the top 6 line of a *.x Denzo output file when it reads them in?
Yes.
The last column in a *.x file, is it used by Scalepack at all?
No.
It appears that the intensity has already had the Lorentz polarization factor applied to it. Is this true?
Yes.