Problems: Difference between revisions

← Older edit

Problems (view source)

Revision as of 11:09, 22 January 2023

4,858 bytes added , 22 January 2023

m

→‎XDS does not start

Kay

Bureaucrats

2,719

edits

@@ Line 1: / Line 1: @@
 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 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 31: / Line 41: @@
 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 32bit operating system ===
+As of March 2021, Thomas Hauß (HZB) reported an OpenMP-related problem that is due to a bug in a library that the ifort compiler links into xds_par. It is unknown to us which version of the compiler has or does not have this bug. The bug has been seen with xds_par (VERSION Jan 31, 2020  BUILT=20200417) and is a crash with error message containing:
+<pre>
-If the error message is e.g.
+OMP: Error #13: Assertion failure at z_Linux_util.cpp(2361).
-  xds: Exec format error. Wrong Architecture.
+OMP: Hint Please submit a bug report with this message, compile and run commands used, and machine configuration info including native compiler and operating system versions. Faster response will be obtained by including all program sources. For information on submitting this issue, please see http://www.intel.com/software/products/support/.
-or
+forrtl: error (76): Abort trap signal
-  -bash: /usr/local/bin/xds: cannot execute binary file
+Image              PC                Routine            Line        Source
-you try to run the 64bit version on a 32bit operating system; this won't work. Since October 2015, you need a 64bit Linux operating system to run XDS because the 32bit version is no longer provided.
+xds_par            00000000005620C4  Unknown               Unknown  Unknown
+libpthread-2.17.s  00002ADC08AAA630  Unknown               Unknown  Unknown
+libc-2.17.so       00002ADC08EF1387  gsignal               Unknown  Unknown
+libc-2.17.so       00002ADC08EF2A78  abort                 Unknown  Unknown
+xds_par            000000000063FB83  Unknown               Unknown  Unknown
+xds_par            000000000062BDFF  Unknown               Unknown  Unknown
+xds_par            000000000060748C  Unknown               Unknown  Unknown
+xds_par            000000000067980E  Unknown               Unknown  Unknown
+xds_par            000000000063D737  Unknown               Unknown  Unknown
+xds_par            000000000063EC58  Unknown               Unknown  Unknown
+xds_par            0000000000629A0E  Unknown               Unknown  Unknown
+xds_par            0000000000419056  xds_                    21586  MAIN_XDS.f90
+xds_par            0000000000418951  MAIN__                      1  MAIN_XDS.f90
+xds_par            0000000000415862  Unknown               Unknown  Unknown
+libc-2.17.so       00002ADC08EDD555  __libc_start_main     Unknown  Unknown
+xds_par            0000000000415769  Unknown               Unknown  Unknown
+</pre>
+The bug is not related to the xds_par source code, but also happens with other software. The workaround is to set the environment variable
+    bash: export KMP_INIT_AT_FORK=FALSE
+    tcsh: setenv KMP_INIT_AT_FORK FALSE
 === ASSERT VIOLATION ===
@@ Line 111: / Line 139: @@
   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
 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) ===
@@ Line 206: / Line 236: @@
 If this does not help, try to refine even less items, e.g. leave out AXIS.
+=== IDXREF prints ERROR IN REFINE !!! RETURN CODE IS IER= 0 ===
+This is due to either wrong inputs in XDS.INP, or due to bad data, e.g. spots from many crystals whose diffraction patterns overlap. The first possibility applies if the diffraction pattern is clean. The second applies if the diffraction pattern is ugly, and unsuitable for indexing. In that case, maybe try a different SPOT_RANGE.
 === IDXREF.LP does not show the expected lattice ===
@@ Line 230: / Line 264: @@
 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 ==