Dear Natalie, On Tue, May 12, 2015 at 02:08:42PM +0100, Natalie Tatum wrote: > Dear Lu, > > Just last week I faced an almost identical problem: iMoslfm had no problem > but XDS failed.
Yes - that happens often because the beam centre recorded in the image header doesn't specify what coordinate system is being used. So these values are often 'program specific' and might even depend on the 'standard program' used for processing at the beamline. Please note that the actual values are nearly always correct (apart from some beamlines that rely solely on def.site files for HKL2000 and don't populate the image header with meaningful values): it is the coordinate convention that is missing. We try to record those specialities on the autoPROC wiki at http://www.globalphasing.com/autoproc/wiki/index.cgi?BeamlineSettings where you could find a lot of settings relevant to XDS processing for different beamlines and detectors. Cheers Clemens PS: we always hope that any change in beamline/detector/header configuration is passed down to software developers before any user starts collecting data ... but most of the time the problems/changes are only discovered after the fact ;-) > I discovered, as Kay has suggested, the ORGX and ORGY > values were incorrect in XDS.INP. In fact, they had essentially been > swapped. If you have AUTOINDEX.INP from fast_dp, you can compare the > values. For me, they were correct in AUTOINDEX.INP but incorrect in > XDS.INP. I'd suggest (because it fixed the problem for me) simply swapping > the values of ORGX and ORGY back, and rerunning XDS. > > HTH > > Natalie > > > On 12 May 2015 at 13:54, Kay Diederichs <kay.diederi...@uni-konstanz.de> > wrote: > > > Dear LU, > > > > yes, your spot_15.png looks good. What worries me now is the table > > > > INDEX_ QUALITY DELTA XD YD X Y Z DH > > DK DL > > ORIGIN > > > > 0 0 0 1.7 0.1 997.7 1020.9 0.0010 0.0005 1.0219 > > 0.38 0.51 0.25 > > 0 -1 0 3.0 0.4 1002.5 1000.4 0.0026 -0.0063 1.0219 > > 0.36 0.27 0.16 > > 0 0 -1 3.3 0.4 972.7 1021.8 -0.0073 0.0009 1.0219 > > 0.30 0.42 0.19 > > 0 -1 -1 4.0 0.5 977.6 1001.3 -0.0057 -0.0059 1.0219 > > 0.34 0.32 0.15 > > 1 -1 0 5.2 0.4 1012.8 1027.9 0.0060 0.0029 1.0219 > > 0.48 0.64 0.30 > > 1 -1 -1 5.4 0.2 988.2 1028.8 -0.0022 0.0032 1.0219 > > 0.58 0.75 0.38 > > 0 0 1 6.0 0.5 1022.8 1019.9 0.0094 0.0002 1.0219 > > 0.48 0.63 0.31 > > 1 0 0 6.2 0.6 1008.1 1048.3 0.0045 0.0097 1.0219 > > 0.28 0.53 0.15 > > 1 0 -1 6.7 0.6 983.3 1049.2 -0.0038 0.0100 1.0219 > > 0.36 0.56 0.19 > > 0 -1 1 7.7 0.7 1027.5 999.4 0.0109 -0.0066 1.0219 > > 0.38 0.26 0.18 > > 0 1 0 7.9 0.4 992.8 1041.6 -0.0006 0.0074 1.0219 > > 0.61 1.05 0.46 > > 0 1 -1 9.6 0.7 967.7 1042.5 -0.0090 0.0077 1.0219 > > 0.50 0.91 0.40 > > 0 -1 -2 10.5 0.8 952.9 1002.3 -0.0139 -0.0056 1.0218 > > 0.35 0.40 0.17 > > ... > > > > That table is based on the assumption of ORGX=994.64 ORGY=1019.22 (the > > values from the header), so IDXREF puts the origin of the reciprocal > > lattice closest to these given values. However, as the table indicates, > > choosing the origin at other places (columns XD YD) would result in much > > lower DH DK DL, so it may well be the case that the values of ORGX ORGY are > > not correct. > > From the frame hg6_L1_1_00001.mccd you posted, I would rather (visually, > > based on beamstop shadow) estimate ORGX ORGY to be at 980 1060 or so. > > If I run (using the SPOT.XDS you posted yesterday) IDXREF with e.g. > > ORGX=994.64 ORGY= 1035 then I get better indexing, and a rather clear > > indication that the space group is orthorhombic: > > INDEX_ QUALITY DELTA XD YD X Y Z DH > > DK DL > > ORIGIN > > > > 0 0 0 1.8 0.2 998.4 1022.2 0.0015 -0.0050 1.2019 > > 0.25 0.35 0.15 > > 0 -1 0 2.5 0.1 994.3 1040.4 -0.0001 0.0021 1.2019 > > 0.38 0.57 0.25 > > 0 0 1 3.3 0.4 977.2 1020.4 -0.0068 -0.0057 1.2019 > > 0.21 0.37 0.14 > > 0 -1 1 4.0 0.4 973.1 1038.5 -0.0084 0.0014 1.2019 > > 0.32 0.52 0.22 > > 0 0 -1 4.7 0.5 1019.7 1024.1 0.0098 -0.0043 1.2019 > > 0.35 0.35 0.18 > > 0 -1 -1 5.3 0.4 1015.5 1042.3 0.0082 0.0029 1.2019 > > 0.45 0.62 0.28 > > and > > LATTICE- BRAVAIS- QUALITY UNIT CELL CONSTANTS (ANGSTROEM & DEGREES) > > CHARACTER LATTICE OF FIT a b c alpha beta gamma > > > > * 44 aP 0.0 64.5 93.3 116.4 90.2 90.0 90.0 > > * 31 aP 0.4 64.5 93.3 116.4 89.8 90.0 90.0 > > * 35 mP 1.0 93.3 64.5 116.4 90.0 90.2 90.0 > > * 33 mP 4.0 64.5 93.3 116.4 90.2 90.0 90.0 > > * 34 mP 4.1 64.5 116.4 93.3 90.2 90.0 90.0 > > * 32 oP 4.5 64.5 93.3 116.4 90.2 90.0 90.0 > > 37 mC 249.9 241.6 64.5 93.3 90.0 90.2 74.5 > > > > I would hypothesize that the beam position is incorrect. Personally, I'd > > use > > JOB= DEFPIX INTEGRATE CORRECT > > ORGX=994.64 ORGY= 1035 > > for a tentative round of integration, maybe together with > > SPACE_GROUP_NUMBER=19 > > UNIT_CELL_CONSTANTS= 64.5 93.3 116.4 90. 90.0 90.0 > > and then inspect the result. If the statistics look reasonable (ISa > 10 > > or so), you should optimize it (see XDSwiki). If it looks very bad (ISa < > > 5), you can run > > echo CENTRE | pointless XDS_ASCII.HKL > > afterwards, which will tell you whether an offset in one of the indices > > has to be applied. In that case, you should inspect the "INDEX ORIGIN" > > table of IDXREF.LP again, to see which ORGX ORGY this corresponds to. After > > this, re-integrate, optimize ... > > > > If you are not successful, compress your frames, upload them to some > > Dropbox-like directory, and send me the link. I'll look at your data, > > treating them confidentially of course, and tell you what I find. > > > > best, > > Kay > > > > > > > > > > > > > > >Dear Kay, > > > > > > I've tune these parameter for many times, and I got best results . : > > > > > >SPOT_RANGE=1 100 > > > > > >INCLUDE_RESOLUTION_RANGE=50 4.2 > > > > > >MINIMUM_NUMBER_OF_PIXELS_IN_A_SPOT=20 > > > > > >but still got the same error message! > > > > > >The SPOT.XDS file was ploted (see attachment "spot_15.png" ), it seems > > that the ice ring and beam stop shadow was excluded. But the result is > > still frustrating. > > > > > > Best wishes! > > > > > >LU zuokun > > > > > > -- > *Natalie J. Tatum* > PhD Researcher > Durham University > http://about.me/n.j.tatum -- *************************************************************** * Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com * * Global Phasing Ltd. * Sheraton House, Castle Park * Cambridge CB3 0AX, UK *-------------------------------------------------------------- * BUSTER Development Group (http://www.globalphasing.com) ***************************************************************
