2,652
edits
Problems: Difference between revisions
Jump to navigation
Jump to search
m
→IDXREF ends with !!! ERROR !!! message
| (4 intermediate revisions by the same user not shown) | |||
| Line 31: | Line 31: | ||
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. | 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. | ||
= | 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> | |||
OMP: Error #13: Assertion failure at z_Linux_util.cpp(2361). | |||
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/. | |||
forrtl: error (76): Abort trap signal | |||
- | Image PC Routine Line Source | ||
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 === | === ASSERT VIOLATION === | ||
| Line 111: | Line 129: | ||
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 234: | Line 254: | ||
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 == | ||