2,652
edits
Problems: Difference between revisions
m
→XDS does not start
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
This is a collection of problems and their solutions. | This is a collection of problems and their solutions. | ||
== XDS does not start == | |||
XDS must be installed in the PATH, i.e. in one of those directories in the filesystem where the shell looks for binaries. On both Linux and macOS, there is a default set of such directories; these typically should have those binaries that the distribution provides. Additional software and its binaries can be installed by the user/admin in different (additional) directories. On macOS, these typically go into /Applications if they come with an installer, but /usr/local/bin could also be used e.g. for single binaries. On Linux, typically large packages have their own directory, often under /opt if they are for all users, or under $HOME for a single user. | |||
The downloading and installation of the XDS package is documented at https://xds.mr.mpg.de/html_doc/downloading.html , and also in [[Installation]]. | |||
The important point is that after unpacking the XDS distribution, the resulting directory should be put into your PATH variable, as explained in the URL above. Failing to do so results in an error message, and a non-functional XDS installation. | |||
For example, if you get the error message (e.g. in the terminal where you started XDSGUI) | |||
/bin/bash: xds_par: command not found | |||
then this means that either the XDS package was not installed at all, or the PATH variable does not point to its directory. | |||
== XDS crashes == | == 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, or (rarely) it is due to improper inputs ([[Problems#INTEGRATE_cell_and.2For_distance_run_away.3B_xds_crashes_or_has_to_be_killed|this]] is the only example I know of). | 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, or (rarely) it is due to improper inputs ([[Problems#INTEGRATE_cell_and.2For_distance_run_away.3B_xds_crashes_or_has_to_be_killed|this]] is the only example I know of). | ||
| Line 57: | Line 67: | ||
bash: export KMP_INIT_AT_FORK=FALSE | bash: export KMP_INIT_AT_FORK=FALSE | ||
tcsh: setenv KMP_INIT_AT_FORK FALSE | tcsh: setenv KMP_INIT_AT_FORK FALSE | ||
=== ASSERT VIOLATION === | === ASSERT VIOLATION === | ||
| Line 138: | Line 139: | ||
THE "DATA_RANGE=" IN FILE "XDS.INP" AND START ALL OVER AGAIN. | THE "DATA_RANGE=" IN FILE "XDS.INP" AND START ALL OVER AGAIN. | ||
This is printed out for you to actually read, and take action accordingly. In most cases you just change the JOB= line in XDS.INP to read | This is printed out for you to actually read, and take action accordingly: it may result from one or more additional crystals contributing to the diffraction patterns. Or it may just be the case that there are ice rings with very many isolated ice reflections (in that case you may want to use EXCLUDE_RESOLUTION_RANGE for the IDXREF task, or just to ignore the message and go on with JOB=DEFPIX INTEGRATE CORRECT). Or you have MINIMUM_NUMBER_OF_PIXELS_IN_A_SPOT of 3, but your reflections comprise many more pixels and COLSPOT may "see" several reflections when there's only one (in that case use MINIMUM_NUMBER_OF_PIXELS_IN_A_SPOT=6 or even 12). In most cases you just change the JOB= line in XDS.INP to read | ||
JOB= DEFPIX INTEGRATE CORRECT | 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). | 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). | ||
See also [[Problems#frame_numbers_beyond_999999]] below. | |||
=== IDXREF produces too short cell parameter(s) === | === IDXREF produces too short cell parameter(s) === | ||
| Line 261: | Line 264: | ||
A final possibility: your crystal may really be triclinic - hopefully you collected 180° of data, or even a bit more than that. | A final possibility: your crystal may really be triclinic - hopefully you collected 180° of data, or even a bit more than that. | ||
=== frame numbers beyond 999999 === | |||
If the number of question marks "?" in NAME_TEMPLATE_OF_DATA_FRAMES is larger than 6, to allow for e.g. | |||
DATA_RANGE= 1000001 10001000 | |||
then IDXREF cannot properly read SPOT.XDS written by COLSPOT, and stops with | |||
!!! ERROR !!! CANNOT READ SPOT.XDS | |||
This happens when the filenames of the frames have digits before the actual number, as in myframe1000001.cbf . | |||
The workaround is to specify e.g. | |||
NAME_TEMPLATE_OF_DATA_FRAMES=myframe100????.cbf | |||
DATA_RANGE=1 1000 | |||
(Problem reported by Pedro Dinis) | |||
== Integration failure == | == Integration failure == | ||