2,684
edits
(→Integration failure: INTEGRATE run-away) |
|||
Line 233: | Line 233: | ||
== Integration failure == | == Integration failure == | ||
=== INTEGRATE stops with error message === | |||
If INTEGRATE stops after e.g. | If INTEGRATE stops after e.g. | ||
****************************************************************************** | ****************************************************************************** | ||
Line 263: | Line 264: | ||
DELPHI=20 ! default is 5, so try with e.g. 10, 20, 45, 90, 180 | DELPHI=20 ! default is 5, so try with e.g. 10, 20, 45, 90, 180 | ||
and re-run INTEGRATE. | and re-run INTEGRATE. | ||
=== INTEGRATE cell and/or distance run away; xds crashes or has to be killed === | |||
If during INTEGRATE the cell keeps increasing or the distance decreasing or both, then xds starts to consume large amounts of memory and becomes very slow. This may finally exhaust all available memory, and the job either crashes or has to be killed by the user. | |||
The fix here is to use | |||
REFINE(INTEGRATE)= BEAM POSITION ORIENTATION ! CELL | |||
instead of (what used to be the default until June 2017) | |||
REFINE(INTEGRATE)= BEAM POSITION ORIENTATION CELL | |||
Quite generally, the more conservative setting without CELL refinement is adequate unless your crystals diffract to quite high resolution. A sure sign that you should not be refining CELL is that the refined cell and/or distance values in INTEGRATE.LP fluctuate without obvious physical reason. Moreover, distance ("POSITION") refinement nicely soaks up any cell change resulting from radiation damage. | |||
A compromise (if you suspect that the cell parameters actually change ''differently'') would be | |||
REFINE(INTEGRATE)= BEAM ORIENTATION CELL ! POSITION | |||
This should also avoid the run-away but gives more freedom to the refinement. Of course it requires a refined distance (from IDXREF, or rather from GXPARM.XDS->XPARM.XDS renaming). | |||
== See also == | == See also == |