Problems
This is a collection of problems and their solutions.
XDS crashes
XDS should never crash (if it terminates with an error message, this does not count as crash). If it does, it is either a bug in the program which should be brought to the attention of Wolfgang Kabsch or Kay Diederichs, and will be fixed, or it is a problem with your computer.
If it crashes for the second reason, these are the things to try/consider:
huge frames leading to overflow of the shell's stack limit
Increase the stack limit of your shell, e.g. (if using csh or tcsh) with
limit stacksize 102400
or (in case of bash)
ulimit -s 102400
The numbers above mean a 10-fold increase over the default, and should be enough. I've found this to be necessary for unusually large frames (32 MB). xds_par in this case also might need an increase of the environment variable OMP_STACKSIZE (e.g. "setenv OMP_STACKSIZE 128M").
memory consumption exceeding the 4GB barrier when using the 32bit binary
As pointed out by James Holton, the memory consumed by huge frames in combination with many threads may be larger than 32 bits allow. Execution then stops with
forrtl: severe (41): insufficient virtual memory
The workaround is to limit the MAXIMUM_NUMBER_OF_PROCESSORS, or to use XDS instead of XDS_PAR. An even better solution is to switch to the 64bit binary, but that of course requires a 64bit operating system.
Problems with OpenMP
If the "xds_par" binary crashed, try "xds". xds_par uses OpenMP for parallelization, which adds complexity. If it works with xds, but not with xds_par, then there is a chance that some environment variable needs to be set/changed. In any case the XDS developers would like to learn about this.
64bit binary on a 32 bit operating system
If the error message is e.g.
xds: Exec format error. Wrong Architecture.
or
-bash: /usr/local/bin/xds: cannot execute binary file
make sure to use the 32bit version of XDS instead - you try to run the 64bit version on a 32bit operating system; this won't work.
CPU without SSE2 support
If the error message is
forrtl: severe (168): Program Exception - illegal instruction Image PC Routine Line Source xds 08055250 Unknown Unknown Unknown xds 0804B3F6 Unknown Unknown Unknown
this means that unfortunately the CPU of your machine is too old to be supported by XDS (which in this respect is compiled with the default options of the ifort compiler). This may happen e.g. with old AMD CPUs that don't support SSE2 (on Linux check the flags field of /proc/cpuinfo for the presence of the sse2 flag).
According to [1] the following Intel-compatible CPUs did not implement SSE2 after SSE2 was introduced (2001):
- AMD CPUs prior to Athlon 64, including all Socket A-based CPUs
- Intel CPUs prior to Pentium 4
- VIA C3
- Transmeta Crusoe
Indexing failures
In case of IDXREF problems, you should definitively inspect FRAME.cbf, using XDS-viewer or adxv.
FRAME.cbf is written by COLSPOT. It shows the last frame of the SPOT_RANGE, together with spot positions that COLSPOT found, marked with white pixels.
FRAME.cbf is also written by INTEGRATE (this overwrites the FRAME.cbf written by COLSPOT). It shows the last frame of the DATA_RANGE, and you should make sure that the predictions (circles) match the observed reflections.
IDXREF ends with message
!!! ERROR !!! SOLUTION IS INACCURATE AUTOMATIC DATA PROCESSING STOPPED. AS THE CRITERIA FOR A GOOD SOLUTION ARE RATHER STRICT, YOU MAY CHOOSE TO CONTINUE DATA PROCESSING AFTER CHANGING THE "JOB="-CARD IN "XDS.INP" TO "JOB= DEFPIX INTEGRATE CORRECT". IF THE BEST SOLUTION IS REALLY NONSENSE YOU SHOULD FIRST HAVE A LOOK AT THE ASCII-FILE "SPOT.XDS". THIS FILE CONTAINS THE INITIAL SPOT LIST SORTED IN DECREASING SPOT INTENSITY. SPOTS NEAR THE END OF THE FILE MAY BE ARTEFACTS AND SHOULD BE ERASED. ALTERNATIVELY YOU MAY TRY DIFFERENT VALUES FOR "INDEX_ORIGIN" AS SUGGESTED IN THE ABOVE LISTING. IF THE CRYSTAL HAS SLIPPED AT THE BEGINNING OF DATA COLLECTION YOU MAY CHOOSE TO SKIP SOME OF THE FIRST FRAMES BY CHANGING THE "DATA_RANGE=" IN FILE "XDS.INP" AND START ALL OVER AGAIN.
This message is printed if the "STANDARD DEVIATION OF SPOT POSITION (PIXELS)" is larger than the MAXIMUM_ERROR_OF_SPOT_POSITION= (default of 3).
The message is printed out for you to actually read, and take action accordingly. In many cases you just change the JOBS - line in XDS.INP to read
JOB= DEFPIX INTEGRATE CORRECT
and then continue to run XDS. In other cases you may want to change SPOT.XDS, or other keywords in XDS.INP (see also below). But in any case this is an important alert that should make you check the correctness of the parameters that describe the data collection (X-RAY_WAVELENGTH, DETECTOR_DISTANCE, ORGX, ORGY, OSCILLATION_RANGE, NAME_TEMPLATE_OF_DATA_FRAMES).
In versions up to and including Dec 6, 2010, the error message often occurs if the spacegroup is given as "0". In that case the "STANDARD DEVIATION OF SPOT POSITION (PIXELS)" from the first indexing (using 3000 reflections) is used, and not the value resulting from refinement, which takes all reflections into account. This is an over-pessimistic approach, and will change in the next version.
IDXREF.LP does not show the expected lattice
By specifying the spacegroup and unitcell, you tell XDS that it should index based on those reflections that match that spacegroup and unitcell. In a sense, you _force_ that spacegroup and cell. This will discard other (spurious?) reflections, and usually leads to a clean list of Bravais lattice possibilities.
If the data reduction fails nevertheless (in terms of bad R-factors and ISa in the CORRECT step), then chances are that you specified some parameter wrongly, or not accurate enough (ORGY and ORGY are the most likely candidates), or that the crystal does not match your idea about its spacegroup and unit cell. Actually the latter happens pretty frequently (which is why it is always the safest way to collect 180° of spindle rotation unless you know your crystals very well; this is also a good strategy in other respects).
If you tell XDS that you do not to know the spacegroup (SPACE_GROUP_NUMBER= 0), then IDXREF takes all observed reflections into account. By design, the spacegroup decision is then postponed until the CORRECT step, or rather to a run of pointless after CORRECT, and it may be not vital to closely inspect IDXREF.LP, because CORRECT.LP has basically the same information, plus more.
none of the lattices in IDXREF.LP (except aP) has a good QUALITY OF FIT
It is a good idea to use many frames for the SPOT_RANGE, (e.g. the first half of the DATA_RANGE, as does the generate_XDS.INP script) for the COLSPOT and IDXREF steps.
It is entirely possible to run COLSPOT for the complete DATA_RANGE (in that case the parameters of SPOT_RANGE are the same as for the DATA_RANGE), and to try smaller SPOT_RANGEs in IDXREF - this means COLSPOT has to be run only once, and the JOBS= line has e.g.
JOBS= IDXREF
only. Maybe some SPOT_RANGE sub-range gives a clear answer. In that case it may be useful to use
REFINE(INTEGRATE)=! AXIS BEAM ORIENTATION CELL DISTANCE
because otherwise the spurious reflections in the other ranges will probably disturb the on-the-fly refinement of parameters.
I've seen datasets where each reflection had a satellite associated with the main reflection, but separate from it. This is well visible in FRAME.cbf written by COLSPOT. In such a case it helps to use
MINIMUM_NUMBER_OF_PIXELS_IN_A_SPOT= 12 ! re-run COLSPOT after changing the parameter !
thus doubling (w.r.t. the default of 6) the required spotsize that makes a reflection be used for indexing. In the latest case this made it possible to index cleanly on a single frame (which is actually not uncommon).
A final possibility: your crystal may really be triclinic - hopefully you collected 180° of data, or even a bit more than that.