How does the definition of box and spot size in Denzo affect autoindexing?
The size of the integration spot affects auto-indexing procedure in two ways:
- the size affects the default value of the longest vector, if the longest vector command is absent from auto.dat file .
- The spot size also affects the signal-to-noise ratio. Only spots above the weak level (default value 5) are used in auto-indexing. You can see these spots in XdisplayF window.
If the spot size is very wrong you may not get enough spots for auto-indexing.
After processing the first image and getting refined values for the various parameters, I then entered the refined parameters, in particular the values for crystal rotx, roty and rotz, into another auto.dat file and processed a different image. However, the values for crystal rotx, roty and rotz that come out of the indexing run are quite different though clearly related. Is this normal and why does it happen? I have to think a bit about whether it changes the indexing - in particular, whether the assignment of F+ and F- is switched. Certainly, if, after running the auto.dat in Denzo , I then redefine again the crystal angles to be consistent with those refined from the first image then the predictions look fine and the refinement proceeds nicely - though in one case CrysX is -366.26 instead of -6.26 but that should not matter. Any advice on this would be welcome.
It is normal for autoindexing with different images to result in indexings related by a lattice symmetry operation. Such a rotation never changes the assignment of F(+) and F(-). No rotation can. Because you can get different solution related by lattice symmetry, you must only do autoindexing once per crystal.
Comment: I would like to remind you that in order to find indexing you need to collect one oscillation image (i.e. without Weissenberg motion) and only later move to Weissenberg mode.
On a second data set from another protein, I found that XdisplayF and Denzo were unable to index from the first oscillation, which was very close to a zone, i.e. it could not get the third axis. Depending on the way I picked peaks, Denzo either failed entirely (with zeros in the matrix) or it found a cell axis of ~1.25 A (as compared to ~164 A). If I chose a frame midway through the data collection, then Denzo indexed quite quickly.
The problem was really quite different. The oscillation range was too large for the combination of resolution and unit cell. Lunes were overlapping and autoindexing failed, by the way this applies to all autoindexing algorithms. When you rotated the crystal you were no longer collecting data down 164A cell and lune overlap was less severe. The right solution is to collect small oscillation sectors down long unit cell axes. If you already have collected large oscillation sectors down the long unit cell restricting autoindexing to using only low resolution data may help. In this case you may try resolution limits 40 6.
Is it possible to create a file of spots for Denzo that comes from more than one image? We have a rather weak diffractor that we would like to get some cell constants on and, in particular, determine whether it is monoclinic or orthorhombic. One image does not seem to be enough to help Denzo make a clean distinction.
Sorry, it is impossible. It may be possible in the future, but it will require substantial change to the program code. You can make clean distinction of monoclinic from orthorhombic during scaling.
I am trying to process data collected on an R-axis using Denzo and my problem is the following: Although I have what seems to be a pretty decent orientation using the R-axis software, when I import an oscillation frame into Denzo , the overlap between predicted and observed spots is far from decent. Some one suggested that I try to obtain a conversion between the angles j x, j y, j z as defined in R-axis and those used by Denzo.
There is conversion for the angles for some space groups, however it is much simpler to do auto-indexing in Denzo. If you still have a problem it is most likely due to mis-indexing. Denzo reverses the definition of x and y axis relative to R-axis software. If you enter x beam and y beam swapped, Denzo may mis-index.
Before we indexed this crystal on an orthorhombic lattice with cell constants of 133.7, 67.6, 35.7. Now the unit cell is primitive monoclinic 61.89 103.76 70.37 90 109.27 90, and distortion index for orthorhombic is 7.36%.
This is why Denzo always outputs 14 best fitting Bravais lattices when autoindexing. Often protein crystal are polymorphic and unit cell is unexpected one.
It seems to me that if one has indexed the diffraction pattern from one image, for example Frame #1. Then after inputing all the parameters determined from this image (such as crystal rotx roty rotz etc.) one should be able to predict other frames, for example Frame #40 with rotx adjusted accordingly. However, the program seems always reindex the new image and somehow ignore the input parameters. I know that because the crystal symmetry would allow many different but equivalent indexings, however, I think consistency in indexing for successive image has its advantages in case that one wants to apply some anisotropic absorption correction. The confusion comes from the misunderstanding that the rotx value should be adjusted for every frame with different starting j -scan value.
You should autoindex only one image per crystal, to have consistent description of crystal orientation, and you should omit the peaks search file peaks.file command on subsequent images.
After Denzo autoindex, should you have a program to output crystal rotx roty rotz if one wants to switch spindle axis and vertical axis. In the case of [unnamed co-conspirator], because odd ratio of cell axes, and same frames resulted in 3 or 4 equivalent autoindex results, but we could not find the location of major zone on the basis of any index results. I have a P21212 diffracted to 2.2A but failed to find major zone, and collected data cross a mirror plane (60% completion after 90 degrees data).
You can use option print zones in Denzo. Or, you can redo the autoindexing with the desired values of spindle axis and vertical axis. Also Scalepack can do the requested calculation.
Also, is there some way to set a resolution cutoff for the peak search? At 2A I have a dark nickel diffraction ring that peak search labels, understandably, with many peaks. This hasn't yet skewed the auto-indexing, as there I can set resolution limits, but it would be nice to be able to avoid those areas in the data at the outset.
Specify resolution limits 20 2.1 before auto-indexing. This will remove all spots found by peak search outside 20 - 2.1A range.
If I have good cell parameters to start with, can the indexing routine use them as given rather than recalculating them from the peak positions? For one image that I have the Denzo autoindexing gives somewhat different cell parameters from what I think are the correct ones, and the refinement then doesn't work as well as it should. I'd like to be able to try fixing the cell parameters and see if it helps.
type...peak search file peaks.file go fix cell [It you did fit cell in auto-indexing] unit cell 98 99 115 90 90 90 and the program will use the unit cell value you supplied. This will work only if the auto-indexing unit cell is close enough (say within 1-2%) of the unit cell specified by your command.
Denzo bug: I am very dissatisfied with the inability of Denzo to correctly predict and integrate low resolution reflections. If one has a .3 mosaic crystal and you have to give it a 1.5 degree mosaicity in order to get a mere prediction of a low resolution reflection, this is ridiculous.
Whoa, fella. The problem is with the wrong value of x beam, y beam and resulting mis-indexing of the image. If all reflections have wrong index, at most random crystal orientations, low resolution reflections will not match predicted pattern. With right beam position mosaicity 0.3 did generate all low and high resolution reflections. Program is OK.
Actually, I did manage to index the 9-deg rotations.
Auto-indexing of 9-deg rotations is tricky and often fails. You were lucky.