Re: [ccp4bb] XDS INP
On Tue, 12 May 2015 17:24:18 -0500, Gerd Rosenbaum rosenb...@anl.gov wrote: ... But no big deal. It's a -1 in one of the axes definitions. There are, as you stated, many more axes definitions and they depend on the geometry of the end station. E.g., at the SBC, the orientation of otherwise identical goniostats is mirror-image between the ID and the BM for reasons of layout of the two beamlines relative to each other. The idea that the axes definitions should be uniform is not practical. Yeah, in principle no big deal, I agree. But the mirror-image concept does not extend to everything: e.g. screws will still be right-handed in the mirror beamline, and motors (in vacuum pumps etc.) will rotate in a given direction in both the beamline and its mirror. Those motors that move devices up/down or left/right may require the other direction in the mirror beamline. The same is true for the spindle motor: if you don't reverse its direction in the mirror beamline, then a user will e.g. not be able to switch measurements of a mounted crystal easily between mirror-related beamlines: s/he will have to use different inputs to data processing programs, and will have to re-index. So yes, the principle is easy to understand, but to make users happy in practice, during beamline commissioning and setup of user operation a conscious decision can and should be made (and yes, I have talked to beamline people who were not aware of this). If that decision is reverse phi, ok, but this needs to be documented in an accessible way. best, Kay
Re: [ccp4bb] XDS INP
According to http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#ROTATION_AXIS= the definition of a positive value in the ROTATION_AXIS= line is: When looking along the axis, the crystal would rotate clockwise when proceeding to the next data image. There is of course no right or wrong when it comes to choosing the direction of rotation. However, conventionally the sense of rotation is positive; only a small minority of beamlines needs a -1 (reverse phi). The problem is that a) beamlines do not usually document this on their webpages, and sometimes change it without notice b) the headers of the frames usually do not document this (exceptions are d*trek and Nexus headers, it seems) Personally, I wish that beamline designers would be aware of the potential problem for users; I suspect they often are not. Life would be easier if all beamlines would use the same convention, and I'm pretty sure that spindle motors can be produced/bought/programmed for both directions. So when a dataset from an unknown beamline is processed, both possibilities need to be tried, and one of them then turns out to be correct. Sorry that I did not earlier think of this, in your case. Usually, the beamline support provides suitable templates for XDS processing. best, Kay
Re: [ccp4bb] XDS INP
Hi Kay,
On Tue, May 12, 2015 at 08:39:24PM +0100, Kay Diederichs wrote:
According to
http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#ROTATION_AXIS=
the definition of a positive value in the ROTATION_AXIS= line is:
When looking along the axis, the crystal would rotate clockwise
when proceeding to the next data image.
I find the even better description in that part of the XDS
documentation is
The direction of the axis is chosen to describe a right-handed
rotation.
which should follow the right-hand rule a la
http://en.wikipedia.org/wiki/Right-hand_rule
The looking along the axis doesn't clearly define if it is (a)
looking from the crystal towards the base of the rotation axis or (b)
from the rotation-axis base towards the crystal.
There is of course no right or wrong when it comes to choosing the
direction of rotation. However, conventionally the sense of rotation
is positive; only a small minority of beamlines needs a -1 (reverse
phi).
Yes: one can always define the rotation axis without the need for a
'-1'. But this has an impact on the chosen lab coordinate system and
therefore might require a change of INCIDENT_BEAM_DIRECTION= and/or
DIRECTION_OF_DETECTOR_{X,y}-AXIS= ... and there might be good reasons
for having those defined in a particular way (eg. to avoid a negative
value for DETECTOR_DISTANCE= or to have them aligned with the
fast/slow changing axis of the image array as X and Y).
The problem is that
a) beamlines do not usually document this on their webpages, and
sometimes change it without notice
Indeed.
Most beamlines are quite good in providing up-to-date XDS.INP
templates that are known to work with data collected on that
beamline. Ideally, the {X,Y}-GEO_CORR files for Pilatus detectors
should also be placed in a public space (and everything else that
might be required). All so that users can process the data again once
they are back in the home lab with more time and less stress - trying
to reproduce what happened by the automatic processing systems
installed on most beamlines (and through that task especially new
users will actually learn what entails good data processing practice).
Personally, I wish that beamline designers would be aware of the
potential problem for users; I suspect they often are not. Life
would be easier if all beamlines would use the same convention, and
I'm pretty sure that spindle motors can be
produced/bought/programmed for both directions.
Sometimes there are restrictions upon beamlines regarding the choice
of coordinate system to be used: this often has to be identical for
everything and all beamlines at a given synchrotron.
Reaching perfection in an imperfect world ;-)
Cheers
Clemens
--
***
* 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)
***
Re: [ccp4bb] XDS INP
Dear Natalie, I try to run my images with fast_dp, but got the error message: Fast_DP installed in: /home/lu/bin/fast_dp_20141205 Starting image: /home/lu/Documents/hg6l3/Hg6_L3_1_2.mccd Number of jobs: 1 Number of cores: 0 Processing images: 1 - 360 Phi range: 112.50 - 472.50 Template: Hg6_L3_1_#.mccd Wavelength: 0.97853 Working in: /home/lu/bin/fast_dp_20141205/bin Autoindexing error: 'sensor' I cannot find any relative document about fast_dp or autoindexing. Do you have any idea? Best! Lu -- 卢作焜 南开大学新生物站A202 在 2015-05-12 21:08:42，Natalie Tatum nataliejta...@gmail.com 写道： Dear Lu, Just last week I faced an almost identical problem: iMoslfm had no problem but XDS failed. 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 DELTAXD YD X Y Z DH DK DL ORIGIN 0 0 0 1.70.1997.7 1020.9 0.0010 0.0005 1.02190.38 0.510.25 0 -1 0 3.00.4 1002.5 1000.4 0.0026 -0.0063 1.02190.36 0.270.16 0 0 -1 3.30.4972.7 1021.8 -0.0073 0.0009 1.02190.30 0.420.19 0 -1 -1 4.00.5977.6 1001.3 -0.0057 -0.0059 1.02190.34 0.320.15 1 -1 0 5.20.4 1012.8 1027.9 0.0060 0.0029 1.02190.48 0.640.30 1 -1 -1 5.40.2988.2 1028.8 -0.0022 0.0032 1.02190.58 0.750.38 0 0 1 6.00.5 1022.8 1019.9 0.0094 0.0002 1.02190.48 0.630.31 1 0 0 6.20.6 1008.1 1048.3 0.0045 0.0097 1.02190.28 0.530.15 1 0 -1 6.70.6983.3 1049.2 -0.0038 0.0100 1.02190.36 0.560.19 0 -1 1 7.70.7 1027.5999.4 0.0109 -0.0066 1.02190.38 0.260.18 0 1 0 7.90.4992.8 1041.6 -0.0006 0.0074 1.02190.61 1.050.46 0 1 -1 9.60.7967.7 1042.5 -0.0090 0.0077 1.02190.50 0.910.40 0 -1 -2 10.50.8952.9 1002.3 -0.0139 -0.0056 1.02180.35 0.400.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_1.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 DELTAXD YD X Y Z DH DK DL ORIGIN 0 0 0 1.80.2998.4 1022.2 0.0015 -0.0050 1.20190.25 0.350.15 0 -1 0 2.50.1994.3 1040.4 -0.0001 0.0021 1.20190.38 0.570.25 0 0 1 3.30.4977.2 1020.4 -0.0068 -0.0057 1.20190.21 0.370.14 0 -1 1 4.00.4973.1 1038.5 -0.0084 0.0014 1.20190.32 0.520.22 0 0 -1 4.70.5 1019.7 1024.1 0.0098 -0.0043 1.20190.35 0.350.18 0 -1 -1 5.30.4 1015.5 1042.3 0.0082 0.0029 1.20190.45 0.620.28 and LATTICE- BRAVAIS- QUALITY UNIT CELL CONSTANTS (ANGSTROEM DEGREES) CHARACTER LATTICE OF FIT a b c alpha beta gamma * 44aP 0.0 64.5 93.3 116.4 90.2 90.0 90.0 * 31aP 0.4 64.5 93.3 116.4 89.8 90.0 90.0 * 35mP 1.0 93.3 64.5 116.4 90.0 90.2 90.0 * 33mP 4.0 64.5 93.3 116.4 90.2 90.0 90.0 * 34mP 4.1 64.5 116.4 93.3 90.2 90.0 90.0 * 32oP 4.5 64.5 93.3 116.4 90.2 90.0 90.0 37mC249.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
Re: [ccp4bb] XDS INP
Hi Clemens,
your suggested description of positive rotation doesn't remove the
ambiguity.
My intuitive way to define positive rotation (in 1994 or so, when
building the SBC) was:
Looking onto the sample, rotation of the sample in mathematically
positive direction
Only later I was told that in HKL (and I believe also d*trek) the
definition was mathematically positive direction for an observer
standing behind the rotary table looking through the base to the sample.
Not the way a user approaches the goniostat's rotary table.
But no big deal. It's a -1 in one of the axes definitions. There are, as
you stated, many more axes definitions and they depend on the geometry
of the end station. E.g., at the SBC, the orientation of otherwise
identical goniostats is mirror-image between the ID and the BM for
reasons of layout of the two beamlines relative to each other. The idea
that the axes definitions should be uniform is not practical.
Regards,
Gerd
On 12.05.2015 16:24, Clemens Vonrhein wrote:
Hi Kay,
On Tue, May 12, 2015 at 08:39:24PM +0100, Kay Diederichs wrote:
According to
http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#ROTATION_AXIS=
the definition of a positive value in the ROTATION_AXIS= line is:
When looking along the axis, the crystal would rotate clockwise
when proceeding to the next data image.
I find the even better description in that part of the XDS
documentation is
The direction of the axis is chosen to describe a right-handed
rotation.
which should follow the right-hand rule a la
http://en.wikipedia.org/wiki/Right-hand_rule
The looking along the axis doesn't clearly define if it is (a)
looking from the crystal towards the base of the rotation axis or (b)
from the rotation-axis base towards the crystal.
There is of course no right or wrong when it comes to choosing the
direction of rotation. However, conventionally the sense of rotation
is positive; only a small minority of beamlines needs a -1 (reverse
phi).
Yes: one can always define the rotation axis without the need for a
'-1'. But this has an impact on the chosen lab coordinate system and
therefore might require a change of INCIDENT_BEAM_DIRECTION= and/or
DIRECTION_OF_DETECTOR_{X,y}-AXIS= ... and there might be good reasons
for having those defined in a particular way (eg. to avoid a negative
value for DETECTOR_DISTANCE= or to have them aligned with the
fast/slow changing axis of the image array as X and Y).
The problem is that
a) beamlines do not usually document this on their webpages, and
sometimes change it without notice
Indeed.
Most beamlines are quite good in providing up-to-date XDS.INP
templates that are known to work with data collected on that
beamline. Ideally, the {X,Y}-GEO_CORR files for Pilatus detectors
should also be placed in a public space (and everything else that
might be required). All so that users can process the data again once
they are back in the home lab with more time and less stress - trying
to reproduce what happened by the automatic processing systems
installed on most beamlines (and through that task especially new
users will actually learn what entails good data processing practice).
Personally, I wish that beamline designers would be aware of the
potential problem for users; I suspect they often are not. Life
would be easier if all beamlines would use the same convention, and
I'm pretty sure that spindle motors can be
produced/bought/programmed for both directions.
Sometimes there are restrictions upon beamlines regarding the choice
of coordinate system to be used: this often has to be identical for
everything and all beamlines at a given synchrotron.
Reaching perfection in an imperfect world ;-)
Cheers
Clemens
Re: [ccp4bb] XDS INP
Dear Lu, Just last week I faced an almost identical problem: iMoslfm had no problem but XDS failed. 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 DELTAXD YD X Y Z DH DK DL ORIGIN 0 0 0 1.70.1997.7 1020.9 0.0010 0.0005 1.0219 0.380.510.25 0 -1 0 3.00.4 1002.5 1000.4 0.0026 -0.0063 1.0219 0.360.270.16 0 0 -1 3.30.4972.7 1021.8 -0.0073 0.0009 1.0219 0.300.420.19 0 -1 -1 4.00.5977.6 1001.3 -0.0057 -0.0059 1.0219 0.340.320.15 1 -1 0 5.20.4 1012.8 1027.9 0.0060 0.0029 1.0219 0.480.640.30 1 -1 -1 5.40.2988.2 1028.8 -0.0022 0.0032 1.0219 0.580.750.38 0 0 1 6.00.5 1022.8 1019.9 0.0094 0.0002 1.0219 0.480.630.31 1 0 0 6.20.6 1008.1 1048.3 0.0045 0.0097 1.0219 0.280.530.15 1 0 -1 6.70.6983.3 1049.2 -0.0038 0.0100 1.0219 0.360.560.19 0 -1 1 7.70.7 1027.5999.4 0.0109 -0.0066 1.0219 0.380.260.18 0 1 0 7.90.4992.8 1041.6 -0.0006 0.0074 1.0219 0.611.050.46 0 1 -1 9.60.7967.7 1042.5 -0.0090 0.0077 1.0219 0.500.910.40 0 -1 -2 10.50.8952.9 1002.3 -0.0139 -0.0056 1.0218 0.350.400.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_1.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 DELTAXD YD X Y Z DH DK DL ORIGIN 0 0 0 1.80.2998.4 1022.2 0.0015 -0.0050 1.2019 0.250.350.15 0 -1 0 2.50.1994.3 1040.4 -0.0001 0.0021 1.2019 0.380.570.25 0 0 1 3.30.4977.2 1020.4 -0.0068 -0.0057 1.2019 0.210.370.14 0 -1 1 4.00.4973.1 1038.5 -0.0084 0.0014 1.2019 0.320.520.22 0 0 -1 4.70.5 1019.7 1024.1 0.0098 -0.0043 1.2019 0.350.350.18 0 -1 -1 5.30.4 1015.5 1042.3 0.0082 0.0029 1.2019 0.450.620.28 and LATTICE- BRAVAIS- QUALITY UNIT CELL CONSTANTS (ANGSTROEM DEGREES) CHARACTER LATTICE OF FIT a b c alpha beta gamma * 44aP 0.0 64.5 93.3 116.4 90.2 90.0 90.0 * 31aP 0.4 64.5 93.3 116.4 89.8 90.0 90.0 * 35mP 1.0 93.3 64.5 116.4 90.0 90.2 90.0 * 33mP 4.0 64.5 93.3 116.4 90.2 90.0 90.0 * 34mP 4.1 64.5 116.4 93.3 90.2 90.0 90.0 * 32oP 4.5 64.5 93.3 116.4 90.2 90.0 90.0 37mC249.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
Re: [ccp4bb] XDS INP
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 -- 卢作焜 南开大学新生物站A202 At 2015-05-11 23:20:55, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: Hi LU, the reason why IDXREF is not indexing smoothly is that the spot positions in your SPOT.XDS are not very meaningful - you pick up a lot of noise! I plotted your SPOT.XDS using %%:-/tmp/luo% gnuplot gnuplot set size square gnuplot set out tmp.png gnuplot set term png nocrop medium size 1280,960 Terminal type set to 'png' Options are 'nocrop medium size 1280,960 ' gnuplot plot 'SPOT.XDS' us 1:2 w dots gnuplot quit and got the attached file tmp.png. This shows: - ice rings - streaks parallel to the x-axis - some modules of the detector behave very differently from others Poor IDXREF tries to make sense of all of this and still somehow manages to come up with something that may be useful for further processing. But the real remedy of the problems would be to properly set the parameters influencing the COLSPOT step. These are documented at http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html (load the page into your browser, and search for occurrences of COLSPOT). The most important ones in this case are probably MINIMUM_NUMBER_OF_PIXELS_IN_A_SPOT=6 ! this is the default STRONG_PIXEL=3! this is the default INCLUDE_RESOLUTION_RANGE =50 0 ! no default, but you could try 50 4 to exclude the ice rings I don't know which values you used (you forgot to post XDS.INP), so I would try with the above first, run COLSPOT, inspect with the gnuplot technique I described, and then modify the parameters until the plot looks more meaningful, at which point IDXREF will most likely happily index. No, this is not fully automatic, but at least it's a logical way forward. good luck, Kay On Mon, 11 May 2015 19:56:33 +0800, luzuok luzuo...@126.com wrote: Dear Karine and Jürgen, The XDS terminated in IDXREF with error message: !! ERROR !!! INSUFFICIENT PERCENTAGE ( 50%) OF INDEXED REFLECTIONS In the COLSPOT, I can see NUMBER OF DIFFRACTION SPOTS LOCATED 53669 IGNORED BECAUSE OF SPOT MAXIMUM OUT OF CENTER 174 IGNORED BECAUSE OF SPOT CLOSE TO UNTRUSTED REGION 450 WEAK SPOTS OMITTED 11753 NUMBER OF DIFFRACTION SPOTS ACCEPTED 41292 It seems that the accepted spots are enough. But I don't know why there are so many spots which cannot be indexed. Best wishes! LU XDS.INP Description: Binary data IDXREF.LP Description: Binary data
Re: [ccp4bb] XDS INP
Dear LU, yes, your spot_15.png looks good. What worries me now is the table INDEX_ QUALITY DELTAXD YD X Y Z DH DK DL ORIGIN 0 0 0 1.70.1997.7 1020.9 0.0010 0.0005 1.02190.38 0.510.25 0 -1 0 3.00.4 1002.5 1000.4 0.0026 -0.0063 1.02190.36 0.270.16 0 0 -1 3.30.4972.7 1021.8 -0.0073 0.0009 1.02190.30 0.420.19 0 -1 -1 4.00.5977.6 1001.3 -0.0057 -0.0059 1.02190.34 0.320.15 1 -1 0 5.20.4 1012.8 1027.9 0.0060 0.0029 1.02190.48 0.640.30 1 -1 -1 5.40.2988.2 1028.8 -0.0022 0.0032 1.02190.58 0.750.38 0 0 1 6.00.5 1022.8 1019.9 0.0094 0.0002 1.02190.48 0.630.31 1 0 0 6.20.6 1008.1 1048.3 0.0045 0.0097 1.02190.28 0.530.15 1 0 -1 6.70.6983.3 1049.2 -0.0038 0.0100 1.02190.36 0.560.19 0 -1 1 7.70.7 1027.5999.4 0.0109 -0.0066 1.02190.38 0.260.18 0 1 0 7.90.4992.8 1041.6 -0.0006 0.0074 1.02190.61 1.050.46 0 1 -1 9.60.7967.7 1042.5 -0.0090 0.0077 1.02190.50 0.910.40 0 -1 -2 10.50.8952.9 1002.3 -0.0139 -0.0056 1.02180.35 0.400.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_1.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 DELTAXD YD X Y Z DH DK DL ORIGIN 0 0 0 1.80.2998.4 1022.2 0.0015 -0.0050 1.20190.25 0.350.15 0 -1 0 2.50.1994.3 1040.4 -0.0001 0.0021 1.20190.38 0.570.25 0 0 1 3.30.4977.2 1020.4 -0.0068 -0.0057 1.20190.21 0.370.14 0 -1 1 4.00.4973.1 1038.5 -0.0084 0.0014 1.20190.32 0.520.22 0 0 -1 4.70.5 1019.7 1024.1 0.0098 -0.0043 1.20190.35 0.350.18 0 -1 -1 5.30.4 1015.5 1042.3 0.0082 0.0029 1.20190.45 0.620.28 and LATTICE- BRAVAIS- QUALITY UNIT CELL CONSTANTS (ANGSTROEM DEGREES) CHARACTER LATTICE OF FIT a b c alpha beta gamma * 44aP 0.0 64.5 93.3 116.4 90.2 90.0 90.0 * 31aP 0.4 64.5 93.3 116.4 89.8 90.0 90.0 * 35mP 1.0 93.3 64.5 116.4 90.0 90.2 90.0 * 33mP 4.0 64.5 93.3 116.4 90.2 90.0 90.0 * 34mP 4.1 64.5 116.4 93.3 90.2 90.0 90.0 * 32oP 4.5 64.5 93.3 116.4 90.2 90.0 90.0 37mC249.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
Re: [ccp4bb] XDS INP
Hi, Also the IXDREF.LP files from yesterday and today suggest that you are having problems with 2 different datasets. Is that correct? IDXREF from yesterday had: NAME_TEMPLATE_OF_DATA_FRAMES=/home/lu/Documents/StructurePro/images/luzk/Hg6/hg6_L1_1_? OSCILLATION_RANGE=0.5000 X-RAY_WAVELENGTH= 0.832010 whereas today’s has: NAME_TEMPLATE_OF_DATA_FRAMES=/home/lu/Documents/StructurePro/images/luzk/Hg6_L3/Hg6_L3_1_?.mccd OSCILLATION_RANGE=1. X-RAY_WAVELENGTH= 0.978530 Huw
Re: [ccp4bb] XDS INP
You found it! XDS.INP needs ROTATION_AXIS=-1 0 0 with this setting, IDXREF indexes more than half of the reflections: REFINED VALUES OF DIFFRACTION PARAMETERS DERIVED FROM 10956 INDEXED SPOTS REFINED PARAMETERS: AXIS BEAM ORIENTATION CELL STANDARD DEVIATION OF SPOTPOSITION (PIXELS) 0.60 STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)0.15 I assume this is beamline BL17B1 from the Taiwanese NSRRC synchrotron, right? Why oh why do they rotate the spindle this way? Kay On Tue, 12 May 2015 14:50:26 +0100, Huw Jenkins h.t.jenk...@me.com wrote: On 12 May 2015, at 13:09, luzuok luzuo...@126.com wrote: STANDARD DEVIATION OF SPINDLE POSITION (DEGREES) 11.13 Is the oscillation range and rotation axis direction correct in your XDS.INP file? Huw
Re: [ccp4bb] XDS INP
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 DELTAXD YD X Y Z DH DK DL ORIGIN 0 0 0 1.70.1997.7 1020.9 0.0010 0.0005 1.0219 0.380.510.25 0 -1 0 3.00.4 1002.5 1000.4 0.0026 -0.0063 1.0219 0.360.270.16 0 0 -1 3.30.4972.7 1021.8 -0.0073 0.0009 1.0219 0.300.420.19 0 -1 -1 4.00.5977.6 1001.3 -0.0057 -0.0059 1.0219 0.340.320.15 1 -1 0 5.20.4 1012.8 1027.9 0.0060 0.0029 1.0219 0.480.640.30 1 -1 -1 5.40.2988.2 1028.8 -0.0022 0.0032 1.0219 0.580.750.38 0 0 1 6.00.5 1022.8 1019.9 0.0094 0.0002 1.0219 0.480.630.31 1 0 0 6.20.6 1008.1 1048.3 0.0045 0.0097 1.0219 0.280.530.15 1 0 -1 6.70.6983.3 1049.2 -0.0038 0.0100 1.0219 0.360.560.19 0 -1 1 7.70.7 1027.5999.4 0.0109 -0.0066 1.0219 0.380.260.18 0 1 0 7.90.4992.8 1041.6 -0.0006 0.0074 1.0219 0.611.050.46 0 1 -1 9.60.7967.7 1042.5 -0.0090 0.0077 1.0219 0.500.910.40 0 -1 -2 10.50.8952.9 1002.3 -0.0139 -0.0056 1.0218 0.350.400.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_1.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 DELTAXD YD X Y Z DH DK DL ORIGIN 0 0 0 1.80.2998.4 1022.2 0.0015 -0.0050 1.2019 0.250.350.15 0 -1 0 2.50.1994.3 1040.4 -0.0001 0.0021 1.2019 0.380.570.25 0 0 1 3.30.4977.2 1020.4 -0.0068 -0.0057 1.2019 0.210.370.14 0 -1 1 4.00.4973.1 1038.5 -0.0084 0.0014 1.2019 0.320.520.22 0 0 -1 4.70.5 1019.7 1024.1 0.0098 -0.0043 1.2019 0.350.350.18 0 -1 -1 5.30.4 1015.5 1042.3 0.0082 0.0029 1.2019 0.450.620.28 and LATTICE- BRAVAIS- QUALITY UNIT CELL CONSTANTS (ANGSTROEM DEGREES) CHARACTER LATTICE OF FIT a b c alpha beta gamma * 44aP 0.0 64.5 93.3 116.4 90.2 90.0 90.0 * 31aP 0.4 64.5 93.3 116.4 89.8 90.0 90.0 * 35mP 1.0 93.3 64.5 116.4 90.0 90.2 90.0 * 33mP 4.0 64.5 93.3 116.4 90.2 90.0 90.0 * 34mP 4.1 64.5
Re: [ccp4bb] XDS INP
On 12 May 2015, at 13:09, luzuok luzuo...@126.com wrote: STANDARD DEVIATION OF SPINDLE POSITION (DEGREES) 11.13 Is the oscillation range and rotation axis direction correct in your XDS.INP file? Huw
Re: [ccp4bb] XDS INP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Natalie, I usually look at the first frame with adxv and estimate the ORGX ORGY (which can be different from the direct beam position) by eye based on shadows (as Kay mentioned before) or ice rings and copy the values into XDS.INP. Regards, Tim On 05/12/2015 03:08 PM, Natalie Tatum wrote: Dear Lu, Just last week I faced an almost identical problem: iMoslfm had no problem but XDS failed. 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 DELTAXD YD X Y Z DH DK DL ORIGIN 0 0 0 1.70.1997.7 1020.9 0.0010 0.0005 1.0219 0.380.510.25 0 -1 0 3.00.4 1002.5 1000.4 0.0026 -0.0063 1.0219 0.360.270.16 0 0 -1 3.30.4972.7 1021.8 -0.0073 0.0009 1.0219 0.300.42 0.19 0 -1 -1 4.00.5977.6 1001.3 -0.0057 -0.0059 1.0219 0.340.320.15 1 -1 0 5.20.4 1012.8 1027.9 0.0060 0.0029 1.0219 0.480.640.30 1 -1 -1 5.40.2988.2 1028.8 -0.0022 0.0032 1.0219 0.580.75 0.38 0 0 1 6.00.5 1022.8 1019.9 0.0094 0.0002 1.0219 0.480.630.31 1 0 0 6.20.6 1008.1 1048.3 0.0045 0.0097 1.0219 0.280.530.15 1 0 -1 6.70.6983.3 1049.2 -0.0038 0.0100 1.0219 0.360.56 0.19 0 -1 1 7.70.7 1027.5999.4 0.0109 -0.0066 1.0219 0.380.260.18 0 1 0 7.90.4992.8 1041.6 -0.0006 0.0074 1.0219 0.611.050.46 0 1 -1 9.60.7967.7 1042.5 -0.0090 0.0077 1.0219 0.500.91 0.40 0 -1 -2 10.50.8952.9 1002.3 -0.0139 -0.0056 1.0218 0.350.400.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_1.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 DELTAXD YD X Y Z DH DK DL ORIGIN 0 0 0 1.80.2998.4 1022.2 0.0015 -0.0050 1.2019 0.250.350.15 0 -1 0 2.50.1994.3 1040.4 -0.0001 0.0021 1.2019 0.380.570.25 0 0 1 3.30.4977.2 1020.4 -0.0068 -0.0057 1.2019 0.210.37 0.14 0 -1 1 4.00.4973.1 1038.5 -0.0084 0.0014 1.2019 0.320.520.22 0 0 -1 4.70.5 1019.7 1024.1 0.0098 -0.0043 1.2019 0.350.350.18 0 -1 -1 5.30.4 1015.5 1042.3 0.0082 0.0029 1.2019 0.450.62 0.28 and LATTICE- BRAVAIS- QUALITY UNIT CELL CONSTANTS (ANGSTROEM DEGREES) CHARACTER LATTICE OF FIT a b c alpha beta gamma * 44aP 0.0 64.5 93.3 116.4 90.2 90.0 90.0 * 31aP 0.4 64.5 93.3 116.4 89.8 90.0 90.0 * 35mP 1.0 93.3 64.5 116.4 90.0 90.2 90.0 * 33mP 4.0 64.5 93.3 116.4 90.2 90.0 90.0 * 34mP 4.1 64.5 116.4 93.3 90.2 90.0 90.0 * 32oP 4.5 64.5 93.3 116.4 90.2 90.0 90.0 37mC249.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
Re: [ccp4bb] XDS INP
Yes! two data sets from one crystal with 2 different wave length. -- 卢作焜 南开大学新生物站A202 在 2015-05-12 22:14:16，Huw Jenkins h.t.jenk...@me.com 写道： Hi, Also the IXDREF.LP files from yesterday and today suggest that you are having problems with 2 different datasets. Is that correct? IDXREF from yesterday had: NAME_TEMPLATE_OF_DATA_FRAMES=/home/lu/Documents/StructurePro/images/luzk/Hg6/hg6_L1_1_? OSCILLATION_RANGE=0.5000 X-RAY_WAVELENGTH= 0.832010 whereas today’s has: NAME_TEMPLATE_OF_DATA_FRAMES=/home/lu/Documents/StructurePro/images/luzk/Hg6_L3/Hg6_L3_1_?.mccd OSCILLATION_RANGE=1. X-RAY_WAVELENGTH= 0.978530 Huw
Re: [ccp4bb] XDS INP
I not so familiar with data collection hardware! I still have a lot to learn. This data set was collected from SSRF(Shanghai China). I don't know how they rotate the spindle. Can you provide me some reference material？ Best wishes! -- 卢作焜 南开大学新生物站A202 At 2015-05-12 22:41:24, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: You found it! XDS.INP needs ROTATION_AXIS=-1 0 0 with this setting, IDXREF indexes more than half of the reflections: REFINED VALUES OF DIFFRACTION PARAMETERS DERIVED FROM 10956 INDEXED SPOTS REFINED PARAMETERS: AXIS BEAM ORIENTATION CELL STANDARD DEVIATION OF SPOTPOSITION (PIXELS) 0.60 STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)0.15 I assume this is beamline BL17B1 from the Taiwanese NSRRC synchrotron, right? Why oh why do they rotate the spindle this way? Kay On Tue, 12 May 2015 14:50:26 +0100, Huw Jenkins h.t.jenk...@me.com wrote: On 12 May 2015, at 13:09, luzuok luzuo...@126.com wrote: STANDARD DEVIATION OF SPINDLE POSITION (DEGREES) 11.13 Is the oscillation range and rotation axis direction correct in your XDS.INP file? Huw
Re: [ccp4bb] XDS INP
Hi As far as I am aware beamline BL17U at Shanghai has what we in the Mosflm world call reverse phi (or in the XDS world you'd want to change the ROTATION AXIS vector). There are often good reasons (to the engineers who have installed the equipment on the beamline) why the crystal rotation is in the opposite direction. Unfortunately no-one bothers to tell us developers, and we have to find out when we get a 'problem' dataset. I believe that James Holton has a pretty comprehensive list of the conventions used on the PX beamlines around the world On 12 May 2015, at 16:04, luzuok wrote: I not so familiar with data collection hardware! I still have a lot to learn. This data set was collected from SSRF(Shanghai China). I don't know how they rotate the spindle. Can you provide me some reference material？ Best wishes! -- 卢作焜 南开大学新生物站A202 At 2015-05-12 22:41:24, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: You found it! XDS.INP needs ROTATION_AXIS=-1 0 0 with this setting, IDXREF indexes more than half of the reflections: REFINED VALUES OF DIFFRACTION PARAMETERS DERIVED FROM 10956 INDEXED SPOTS REFINED PARAMETERS: AXIS BEAM ORIENTATION CELL STANDARD DEVIATION OF SPOTPOSITION (PIXELS) 0.60 STANDARD DEVIATION OF SPINDLE POSITION (DEGREES)0.15 I assume this is beamline BL17B1 from the Taiwanese NSRRC synchrotron, right? Why oh why do they rotate the spindle this way? Kay On Tue, 12 May 2015 14:50:26 +0100, Huw Jenkins h.t.jenk...@me.com wrote: On 12 May 2015, at 13:09, luzuok luzuo...@126.com wrote: STANDARD DEVIATION OF SPINDLE POSITION (DEGREES) 11.13 Is the oscillation range and rotation axis direction correct in your XDS.INP file? Huw Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge CB2 0QH Chairman of International Union of Crystallography Commission on Crystallographic Computing Chairman of European Crystallographic Association SIG9 (Crystallographic Computing)
Re: [ccp4bb] XDS INP
Edit your XDS.INP file to look like this:
!JOB= XYCORR INIT COLSPOT IDXREF
JOB=DEFPIX INTEGRATE CORRECT
Then rerun ads and be happy thereafter.
and RTFM !
Jürgen
..
Jürgen Bosch
Johns Hopkins University
Bloomberg School of Public Health
Department of Biochemistry Molecular Biology
Johns Hopkins Malaria Research Institute
615 North Wolfe Street, W8708
Baltimore, MD 21205
Office: +1-410-614-4742tel:%2B1-410-614-4742
Lab: +1-410-614-4894tel:%2B1-410-614-4894
Fax: +1-410-955-2926tel:%2B1-410-955-2926
http://lupo.jhsph.edu
On May 11, 2015, at 9:19 AM, Harry Powell
ha...@mrc-lmb.cam.ac.ukmailto:ha...@mrc-lmb.cam.ac.uk wrote:
Hi Lu
Mosflm indexes your image using all defaults without any problems ;-)
XDS shouldn't have any difficulties with indexing this.
I suspect your crystal only diffracts to ~3.0 - 3.5 Å so you could do a better
experiment by moving the detector back to ~ 900mm...
BUT - PLEASE don't attach your original images to messages to the BB - anyone
on a slow data link will be considerably indisposed by having an 8Mb attachment
that they (most probably) really don't want to have.
On 11 May 2015, at 12:56, luzuok wrote:
Dear Karine and Jürgen,
The XDS terminated in IDXREF with error message:
!! ERROR !!! INSUFFICIENT PERCENTAGE ( 50%) OF INDEXED REFLECTIONS
In the COLSPOT, I can see
NUMBER OF DIFFRACTION SPOTS LOCATED 53669
IGNORED BECAUSE OF SPOT MAXIMUM OUT OF CENTER 174
IGNORED BECAUSE OF SPOT CLOSE TO UNTRUSTED REGION 450
WEAK SPOTS OMITTED 11753
NUMBER OF DIFFRACTION SPOTS ACCEPTED 41292
It seems that the accepted spots are enough. But I don't know why there are so
many spots which cannot be indexed.
Best wishes!
LU
--
卢作焜
南开大学新生物站A202
在 2015-05-11 16:49:53，Karine Sparta
karine.spa...@helmholtz-berlin.demailto:karine.spa...@helmholtz-berlin.de
写道：
Dear Lu,
I'm sorry to read that you couldn't process your data with XDSAPP.
I've been busy last week updating our webpage, the latest version of XDSAPP is
now available for download since friday (an official announcement will be made
tomorrow).
Maybe it will help with your data set, if not, I would be interested in the
reason for the failure (IDXREF.LP), I may learn something from it to improve
the next version.
Best regards,
Karine Sparta
On 05/10/15 10:30, luzuok wrote:
Dear all,
Thank you for all your excellent suggestions! The XDS package now works
smoothly in xdsapp in my Linux.
Unfortunately, due to the data quality or maybe my ability, the process was
failed.
Best wishes!
Lu Zuokun
--
卢作焜
南开大学新生物站A202
At 2015-05-08 03:39:07, Clemens Vonrhein
vonrh...@globalphasing.commailto:vonrh...@globalphasing.com wrote:
Dear Lu,
apart from the other excellent advice you got: autoPROC is another
pipeline that uses XDS under the hood (among other tools) and tries to
take most of the pain out of getting started with XDS. For free (to
academics) licences/download please see
http://www.globalphasing.com/autoproc/
Cheers
Clemens
On Thu, May 07, 2015 at 04:33:38PM +0800, luzuok wrote:
Dear all,
I'm a XDS beginner and the first problem I encounter was the INP file.
The detector type is MX300. Is the detector supported by XDS? How to
modified the INP file?
The sitefile of HKL2000 was attached.
Can anyone provide some tutorial to use XDS?
Best wishes!
Lu zuokun
--
卢作焜
南开大学新生物站A202
[-- octet-filter file type: ASCII text --]
HKLSuite0.95SITE
{alig,1} {180}
{beamline_name} {BL17B}
{cass,rotx} {-0.119}
{cass,roty} {-0.167}
{crossx} {0.044}
{crossxy} {0.009}
{crossy} {0.001}
{detec} {CCD unsupported-m300}
{extension} {*.mccd}
{last_saved,chix} {3.24}
{last_saved,chiy} {1.65}
{last_saved,date} {17:11:17 Apr 19, 2015}
{last_saved,user} {17bdata1}
{polar} {0.99}
{rotation_axis} {Phi}
{synchrotron_name} {SSRF}
{xbeam} {149.336}
{y_scale} {1}
{ybeam} {145.711}
--
***
* 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.comhttp://www.globalphasing.com/)
***
--
Dr. Karine Sparta
Soft Matter and Functional Materials
Macromolecular Crystallography (BESSY-MX)
Elektronenspeicherring BESSY II
Albert-Einstein-Str. 15, D-12489 Berlin, Germany
Fon: +49 30 8062 14869
http://de.linkedin.com/pub/karine-sparta/2a/48/1b3/en
Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.
Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv.
Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking
Sitz Berlin, AG
Re: [ccp4bb] XDS INP
Hi Lu
Mosflm indexes your image using all defaults without any problems ;-)
XDS shouldn't have any difficulties with indexing this.
I suspect your crystal only diffracts to ~3.0 - 3.5 Å so you could do a better
experiment by moving the detector back to ~ 900mm...
BUT - PLEASE don't attach your original images to messages to the BB - anyone
on a slow data link will be considerably indisposed by having an 8Mb attachment
that they (most probably) really don't want to have.
On 11 May 2015, at 12:56, luzuok wrote:
Dear Karine and Jürgen,
The XDS terminated in IDXREF with error message:
!! ERROR !!! INSUFFICIENT PERCENTAGE ( 50%) OF INDEXED REFLECTIONS
In the COLSPOT, I can see
NUMBER OF DIFFRACTION SPOTS LOCATED 53669
IGNORED BECAUSE OF SPOT MAXIMUM OUT OF CENTER 174
IGNORED BECAUSE OF SPOT CLOSE TO UNTRUSTED REGION 450
WEAK SPOTS OMITTED 11753
NUMBER OF DIFFRACTION SPOTS ACCEPTED 41292
It seems that the accepted spots are enough. But I don't know why there are
so many spots which cannot be indexed.
Best wishes!
LU
--
卢作焜
南开大学新生物站A202
在 2015-05-11 16:49:53，Karine Sparta karine.spa...@helmholtz-berlin.de 写道：
Dear Lu,
I'm sorry to read that you couldn't process your data with XDSAPP.
I've been busy last week updating our webpage, the latest version of XDSAPP
is now available for download since friday (an official announcement will be
made tomorrow).
Maybe it will help with your data set, if not, I would be interested in the
reason for the failure (IDXREF.LP), I may learn something from it to improve
the next version.
Best regards,
Karine Sparta
On 05/10/15 10:30, luzuok wrote:
Dear all,
Thank you for all your excellent suggestions! The XDS package now works
smoothly in xdsapp in my Linux.
Unfortunately, due to the data quality or maybe my ability, the process was
failed.
Best wishes!
Lu Zuokun
--
卢作焜
南开大学新生物站A202
At 2015-05-08 03:39:07, Clemens Vonrhein vonrh...@globalphasing.com
wrote:
Dear Lu,
apart from the other excellent advice you got: autoPROC is another
pipeline that uses XDS under the hood (among other tools) and tries to
take most of the pain out of getting started with XDS. For free (to
academics) licences/download please see
http://www.globalphasing.com/autoproc/
Cheers
Clemens
On Thu, May 07, 2015 at 04:33:38PM +0800, luzuok wrote:
Dear all,
I'm a XDS beginner and the first problem I encounter was the INP
file. The detector type is MX300. Is the detector supported by XDS? How
to modified the INP file?
The sitefile of HKL2000 was attached.
Can anyone provide some tutorial to use XDS?
Best wishes!
Lu zuokun
--
卢作焜
南开大学新生物站A202
[-- octet-filter file type: ASCII text --]
HKLSuite0.95SITE
{alig,1} {180}
{beamline_name} {BL17B}
{cass,rotx} {-0.119}
{cass,roty} {-0.167}
{crossx} {0.044}
{crossxy} {0.009}
{crossy} {0.001}
{detec} {CCD unsupported-m300}
{extension} {*.mccd}
{last_saved,chix} {3.24}
{last_saved,chiy} {1.65}
{last_saved,date} {17:11:17 Apr 19, 2015}
{last_saved,user} {17bdata1}
{polar} {0.99}
{rotation_axis} {Phi}
{synchrotron_name} {SSRF}
{xbeam} {149.336}
{y_scale} {1}
{ybeam} {145.711}
--
***
* 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)
***
--
Dr. Karine Sparta
Soft Matter and Functional Materials
Macromolecular Crystallography (BESSY-MX)
Elektronenspeicherring BESSY II
Albert-Einstein-Str. 15, D-12489 Berlin, Germany
Fon: +49 30 8062 14869
http://de.linkedin.com/pub/karine-sparta/2a/48/1b3/en
Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren
e.V.
Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv.
Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking
Sitz Berlin, AG Charlottenburg, 89 HRB 5583
Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin
http://www.helmholtz-berlin.de
IDXREF.LPhg6_L1_1_1.mccdSPOT.XDS
Harry
--
Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick Avenue,
Cambridge Biomedical Campus, Cambridge CB2 0QH
Chairman of International Union of Crystallography Commission on
Crystallographic Computing
Chairman of European Crystallographic Association SIG9 (Crystallographic
Computing)
Re: [ccp4bb] XDS INP
Hi LU, the reason why IDXREF is not indexing smoothly is that the spot positions in your SPOT.XDS are not very meaningful - you pick up a lot of noise! I plotted your SPOT.XDS using %%:-/tmp/luo% gnuplot gnuplot set size square gnuplot set out tmp.png gnuplot set term png nocrop medium size 1280,960 Terminal type set to 'png' Options are 'nocrop medium size 1280,960 ' gnuplot plot 'SPOT.XDS' us 1:2 w dots gnuplot quit and got the attached file tmp.png. This shows: - ice rings - streaks parallel to the x-axis - some modules of the detector behave very differently from others Poor IDXREF tries to make sense of all of this and still somehow manages to come up with something that may be useful for further processing. But the real remedy of the problems would be to properly set the parameters influencing the COLSPOT step. These are documented at http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html (load the page into your browser, and search for occurrences of COLSPOT). The most important ones in this case are probably MINIMUM_NUMBER_OF_PIXELS_IN_A_SPOT=6 ! this is the default STRONG_PIXEL=3! this is the default INCLUDE_RESOLUTION_RANGE =50 0 ! no default, but you could try 50 4 to exclude the ice rings I don't know which values you used (you forgot to post XDS.INP), so I would try with the above first, run COLSPOT, inspect with the gnuplot technique I described, and then modify the parameters until the plot looks more meaningful, at which point IDXREF will most likely happily index. No, this is not fully automatic, but at least it's a logical way forward. good luck, Kay On Mon, 11 May 2015 19:56:33 +0800, luzuok luzuo...@126.com wrote: Dear Karine and Jürgen, The XDS terminated in IDXREF with error message: !! ERROR !!! INSUFFICIENT PERCENTAGE ( 50%) OF INDEXED REFLECTIONS In the COLSPOT, I can see NUMBER OF DIFFRACTION SPOTS LOCATED 53669 IGNORED BECAUSE OF SPOT MAXIMUM OUT OF CENTER 174 IGNORED BECAUSE OF SPOT CLOSE TO UNTRUSTED REGION 450 WEAK SPOTS OMITTED 11753 NUMBER OF DIFFRACTION SPOTS ACCEPTED 41292 It seems that the accepted spots are enough. But I don't know why there are so many spots which cannot be indexed. Best wishes! LU
Re: [ccp4bb] XDS INP
Dear all,
Thank you for all your excellent suggestions! The XDS package now works
smoothly in xdsapp in my Linux.
Unfortunately, due to the data quality or maybe my ability, the process was
failed.
Best wishes!
Lu Zuokun
--
卢作焜
南开大学新生物站A202
At 2015-05-08 03:39:07, Clemens Vonrhein vonrh...@globalphasing.com wrote:
Dear Lu,
apart from the other excellent advice you got: autoPROC is another
pipeline that uses XDS under the hood (among other tools) and tries to
take most of the pain out of getting started with XDS. For free (to
academics) licences/download please see
http://www.globalphasing.com/autoproc/
Cheers
Clemens
On Thu, May 07, 2015 at 04:33:38PM +0800, luzuok wrote:
Dear all,
I'm a XDS beginner and the first problem I encounter was the INP file.
The detector type is MX300. Is the detector supported by XDS? How to
modified the INP file?
The sitefile of HKL2000 was attached.
Can anyone provide some tutorial to use XDS?
Best wishes!
Lu zuokun
--
卢作焜
南开大学新生物站A202
[-- octet-filter file type: ASCII text --]
HKLSuite0.95SITE
{alig,1} {180}
{beamline_name} {BL17B}
{cass,rotx} {-0.119}
{cass,roty} {-0.167}
{crossx} {0.044}
{crossxy} {0.009}
{crossy} {0.001}
{detec} {CCD unsupported-m300}
{extension} {*.mccd}
{last_saved,chix} {3.24}
{last_saved,chiy} {1.65}
{last_saved,date} {17:11:17 Apr 19, 2015}
{last_saved,user} {17bdata1}
{polar} {0.99}
{rotation_axis} {Phi}
{synchrotron_name} {SSRF}
{xbeam} {149.336}
{y_scale} {1}
{ybeam} {145.711}
--
***
* 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)
***
Re: [ccp4bb] XDS INP
The process failed.
You mean it didn’t process the data past the indexing routine?
That just means you need to actually change some values and type in a couple of
commands into XDS.INP - not everything can be designed to be point click.
Look at IDXREF.LP and check out what the suggested space group is, then change
that in XDS.INP and provide the correct cell dimensions. Change the JOB card to
start with DEFPIX and remove the previous sub routines.
Look at the manual of XDS on Kabsch’s website.
Jürgen
..
Jürgen Bosch
Johns Hopkins University
Bloomberg School of Public Health
Department of Biochemistry Molecular Biology
Johns Hopkins Malaria Research Institute
615 North Wolfe Street, W8708
Baltimore, MD 21205
Office: +1-410-614-4742tel:%2B1-410-614-4742
Lab: +1-410-614-4894tel:%2B1-410-614-4894
Fax: +1-410-955-2926tel:%2B1-410-955-2926
http://lupo.jhsph.edu
On May 10, 2015, at 4:30 AM, luzuok luzuo...@126.commailto:luzuo...@126.com
wrote:
Dear all,
Thank you for all your excellent suggestions! The XDS package now works
smoothly in xdsapp in my Linux.
Unfortunately, due to the data quality or maybe my ability, the process was
failed.
Best wishes!
Lu Zuokun
--
卢作焜
南开大学新生物站A202
At 2015-05-08 03:39:07, Clemens Vonrhein
vonrh...@globalphasing.commailto:vonrh...@globalphasing.com wrote:
Dear Lu,
apart from the other excellent advice you got: autoPROC is another
pipeline that uses XDS under the hood (among other tools) and tries to
take most of the pain out of getting started with XDS. For free (to
academics) licences/download please see
http://www.globalphasing.com/autoproc/
Cheers
Clemens
On Thu, May 07, 2015 at 04:33:38PM +0800, luzuok wrote:
Dear all,
I'm a XDS beginner and the first problem I encounter was the INP file.
The detector type is MX300. Is the detector supported by XDS? How to
modified the INP file?
The sitefile of HKL2000 was attached.
Can anyone provide some tutorial to use XDS?
Best wishes!
Lu zuokun
--
卢作焜
南开大学新生物站A202
[-- octet-filter file type: ASCII text --]
HKLSuite0.95SITE
{alig,1} {180}
{beamline_name} {BL17B}
{cass,rotx} {-0.119}
{cass,roty} {-0.167}
{crossx} {0.044}
{crossxy} {0.009}
{crossy} {0.001}
{detec} {CCD unsupported-m300}
{extension} {*.mccd}
{last_saved,chix} {3.24}
{last_saved,chiy} {1.65}
{last_saved,date} {17:11:17 Apr 19, 2015}
{last_saved,user} {17bdata1}
{polar} {0.99}
{rotation_axis} {Phi}
{synchrotron_name} {SSRF}
{xbeam} {149.336}
{y_scale} {1}
{ybeam} {145.711}
--
***
* 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)
***
Re: [ccp4bb] XDS INP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Lu zuokun, the web site http://homes.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/detectors.html lists all the detectors supported by XDS. There are some graphical user interfaces for XDS which are very good not only for beginners. One I can recommend is XDSGUI by Kay Diederichs, available at http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/XDSGUI Another one is xdsapp (http://www.helmholtz-berlin.de/forschung/oe/em/soft-matter/forschung/bessy-mx/xdsapp/index_en.html) I recommend trying one of those to get started. Best, Tim On 05/07/2015 10:33 AM, luzuok wrote: Dear all, I'm a XDS beginner and the first problem I encounter was the INP file. The detector type is MX300. Is the detector supported by XDS? How to modified the INP file? The sitefile of HKL2000 was attached. Can anyone provide some tutorial to use XDS? Best wishes! Lu zuokun -- 卢作焜 南开大学新生物站A202 - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen phone: +49 (0)551 39 22149 GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1 iD8DBQFVSynzUxlJ7aRr7hoRAltsAKCTWwhMYIJxcnEPrtuR4bK1SIdx0wCg63xi xuj+552PZUl2GDkyb75P3QQ= =bJ7y -END PGP SIGNATURE-
Re: [ccp4bb] XDS INP
Dear Fred,
Actually I'm not very sure the detector type is MX300. The site file of
HKL2000 is in the folder called MX300. I guess the detector is MX300 because
there are another folder call PILATUS6M.
In the def.site, I can see
{dectec} {CCD unsupported-m300}.
And there seems no m300 dectector supported by XDS.
Regards！
Lu
--
卢作焜
南开大学新生物站A202
在 2015-05-07 16:59:36，vellieux frederic.velli...@ibs.fr 写道：
Hi,
I don't know what an MX300 detector is. From the template input files provided
with XDS, I see the following:
XDS-ADSC.INP XDS-MAR345.INP XDS-PILATUS_200K.INPXDS-SATURN.INP
XDS-BRANDEIS_B4.INP XDS-MAR555.INP XDS-PILATUS.INPXDS-SIEMENS.INP
XDS-CCDBRANDEIS.INP XDS-MARCCD.INPXDS-RAXIS2.INP XDS-SMARTCCD.INP
XDS-MAR.INPXDS-RAXIS4.INP XDS-STOE.INP
XDS-Eiger.INP XDS-PILATUS_12M.INPXDS-RAXIS5.INP
Normally what you do is to copy one of the above XDS input files (corresponding
to your detector) to a file called XDS.INP and modify that in order to fix any
changes in detector size, number of pixels... (if necessary - normally it
shouldn't be) and to provide the correct data to XDS.
Hope this helps,
Fred.
On 07/05/15 10:33, luzuok wrote:
Dear all,
I'm a XDS beginner and the first problem I encounter was the INP file. The
detector type is MX300. Is the detector supported by XDS? How to modified the
INP file?
The sitefile of HKL2000 was attached.
Can anyone provide some tutorial to use XDS?
Best wishes!
Lu zuokun
--
卢作焜
南开大学新生物站A202
--
Fred. Vellieux (B.Sc., Ph.D., hdr)
IBS / ELMA
Campus EPN
71 avenue des Martyrs
CS 10090
F-38044 Grenoble Cedex 9
Tel: +33 457428605
Fax: +33 476501890
Re: [ccp4bb] XDS INP
Dear All,
Starting from here I would just use the generate_XDS.INP script developed
by Kay Diederichs:
http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Generate_XDS.INP
It will make the necessary input files from just the image headers.
best wishes Graeme
On Thu, May 7, 2015 at 11:34 AM Tim Gruene t...@shelx.uni-ac.gwdg.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Lu,
according to the file ending (mccd) in the def-file, you collected
data with a MAR CCD detector. The template file XDS-MARCCD.INP handles
those. The pixel size, etc. are taken automatically from the frame
headers. This detector type is also supported by XDSGUI which would
generate XDS.INP for you.
Best,
Tim
On 05/07/2015 11:19 AM, luzuok wrote:
Dear Fred, Actually I'm not very sure the detector type is MX300.
The site file of HKL2000 is in the folder called MX300. I guess
the detector is MX300 because there are another folder call
PILATUS6M. In the def.site, I can see {dectec} {CCD
unsupported-m300}. And there seems no m300 dectector supported by
XDS.
Regards！ Lu
-- 卢作焜 南开大学新生物站A202
在 2015-05-07 16:59:36，vellieux frederic.velli...@ibs.fr 写道：
Hi,
I don't know what an MX300 detector is. From the template input
files provided with XDS, I see the following:
XDS-ADSC.INP XDS-MAR345.INP XDS-PILATUS_200K.INP
XDS-SATURN.INP XDS-BRANDEIS_B4.INP XDS-MAR555.INP XDS-PILATUS.INP
XDS-SIEMENS.INP XDS-CCDBRANDEIS.INP XDS-MARCCD.INP
XDS-RAXIS2.INP XDS-SMARTCCD.INP XDS-MAR.INP XDS-RAXIS4.INP
XDS-STOE.INP XDS-Eiger.INP XDS-PILATUS_12M.INPXDS-RAXIS5.INP
Normally what you do is to copy one of the above XDS input files
(corresponding to your detector) to a file called XDS.INP and
modify that in order to fix any changes in detector size, number
of pixels... (if necessary - normally it shouldn't be) and to
provide the correct data to XDS.
Hope this helps,
Fred.
On 07/05/15 10:33, luzuok wrote:
Dear all, I'm a XDS beginner and the first problem I encounter was
the INP file. The detector type is MX300. Is the detector
supported by XDS? How to modified the INP file? The sitefile of
HKL2000 was attached. Can anyone provide some tutorial to use XDS?
Best wishes!
Lu zuokun
-- 卢作焜 南开大学新生物站A202
- --
- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen
phone: +49 (0)551 39 22149
GPG Key ID = A46BEE1A
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iD8DBQFVSz7zUxlJ7aRr7hoRAgqcAJsH6Rgrs9mDcvlYZ3ObFV1Q4+FSVACfRwH3
BZ2l+s1kRKwsh2qWaih0rxg=
=Nulf
-END PGP SIGNATURE-
Re: [ccp4bb] XDS INP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Lu,
according to the file ending (mccd) in the def-file, you collected
data with a MAR CCD detector. The template file XDS-MARCCD.INP handles
those. The pixel size, etc. are taken automatically from the frame
headers. This detector type is also supported by XDSGUI which would
generate XDS.INP for you.
Best,
Tim
On 05/07/2015 11:19 AM, luzuok wrote:
Dear Fred, Actually I'm not very sure the detector type is MX300.
The site file of HKL2000 is in the folder called MX300. I guess
the detector is MX300 because there are another folder call
PILATUS6M. In the def.site, I can see {dectec} {CCD
unsupported-m300}. And there seems no m300 dectector supported by
XDS.
Regards！ Lu
-- 卢作焜 南开大学新生物站A202
在 2015-05-07 16:59:36，vellieux frederic.velli...@ibs.fr 写道：
Hi,
I don't know what an MX300 detector is. From the template input
files provided with XDS, I see the following:
XDS-ADSC.INP XDS-MAR345.INP XDS-PILATUS_200K.INP
XDS-SATURN.INP XDS-BRANDEIS_B4.INP XDS-MAR555.INP XDS-PILATUS.INP
XDS-SIEMENS.INP XDS-CCDBRANDEIS.INP XDS-MARCCD.INP
XDS-RAXIS2.INP XDS-SMARTCCD.INP XDS-MAR.INP XDS-RAXIS4.INP
XDS-STOE.INP XDS-Eiger.INP XDS-PILATUS_12M.INPXDS-RAXIS5.INP
Normally what you do is to copy one of the above XDS input files
(corresponding to your detector) to a file called XDS.INP and
modify that in order to fix any changes in detector size, number
of pixels... (if necessary - normally it shouldn't be) and to
provide the correct data to XDS.
Hope this helps,
Fred.
On 07/05/15 10:33, luzuok wrote:
Dear all, I'm a XDS beginner and the first problem I encounter was
the INP file. The detector type is MX300. Is the detector
supported by XDS? How to modified the INP file? The sitefile of
HKL2000 was attached. Can anyone provide some tutorial to use XDS?
Best wishes!
Lu zuokun
-- 卢作焜 南开大学新生物站A202
- --
- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen
phone: +49 (0)551 39 22149
GPG Key ID = A46BEE1A
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iD8DBQFVSz7zUxlJ7aRr7hoRAgqcAJsH6Rgrs9mDcvlYZ3ObFV1Q4+FSVACfRwH3
BZ2l+s1kRKwsh2qWaih0rxg=
=Nulf
-END PGP SIGNATURE-
