Re: [ccp4bb] P321 space group reindex problem
Hi, it is therefore likely that your spacegroup is really P321... hopefully, your data set is not twinned, did you check that ? You are left with 2 possible indexing schemes, as already mentionned. Chek scaling derivative / native scaling for each indexation of the derivative : the lowest Rfactor will likely indicate the right one. It appears that you end up with Rfactor of about 29 %, which suggest that your derivatives are not isomorphous to your native dataset. How do cell parameters compare for each data set ? Check also how the Rfactor varies with resolution, you might still have usefull phasing info at low resolution. hope this helps laurent Le 30/05/2012 07:50, Qixu Cai a écrit : At first, I processed the data at P3 space group. But after phenix.xtriage analysis, the Xtriage told me the space group must be P321, so I used P321 to process my data, and got an acceptable Rmerge. Qixu Cai 2012/5/29 Phil Evans p...@mrc-lmb.cam.ac.uk mailto:p...@mrc-lmb.cam.ac.uk How do you know the point group is 321? What does Pointless tell you if you put in the unmerged data? Despite some of the things said earlier (by me!), the possible indexing schemes in 321 are h,k,l and -h,-k,l If that doesn't work, it suggests that the point group is a lower symmetry eg P3 Phil On 29 May 2012, at 16:29, Qixu Cai wrote: Dear all, thank you for your help. I think I must describe my case in detail. I collected a native dataset and two heavy atom derivant datasets （in fact, i don not know whether these two kind of heavy atom have soked into the crystal, i just collect the data to check it）. i processed all of three datasets with automar, and merged them by CAD. I used scaleit to get the Rfactor between datasets and got a strange result. the R factor between derivant1 and native is 26% and the R factor between derivant2 and native is 59%! so I think it may be the problem of index （space group is P321）. so i exchange the h and k of derivant2 by the some awk script and merged to native data by CAD. After scaleit analysis, I got the R factor 29% between derivant2 and native. Here is my questions, 1, at my case, is that right to invert the hand? is that the special problem of the P3 or p321 space group? 2, I have carryed out some suggestion of yours, such as use pointless （use native data as reference for derivant2 reindex）, or reindex the derivant2 dataset by （k, h, -l）, and I always got the high R factor 59% between derivant2 and native. Any suggestion? thanks a lot! Qixu Cai 在 2012-5-29，下午10:36，Laurent Maveyraud laurent.maveyr...@ipbs.fr mailto:laurent.maveyr...@ipbs.fr 写道： Hi... and apologies ! I was a little quick in my answer... in P321, h k l and -h -k l are valid indexing schemes... It is in P3 that you can have h k l and k h -l as Ian and Phil agreed on the BB ! sorry, laurent Hi, you might have several possible spacegroups possible when processing your data (at the indexation step). These will be based on the metrics of your cell (vector length and angles). If you happen to have something like a = b, and alpha=beta90° and gamma=120°, then it is likely that your crystal is trigonal or hexagonal. You will have to wait until the scaling step (or pointless after integration) in order to decide which spacegroup is the right one, based on the symmetry operations in your dataset and on systematic absences. There you have to choose between P3, P31, P32, P312, P321 in trigonal. When comparing two datasets from trigonal crystals, even for identical crystals and hence identical spacegroups, you have different ways to index your dataset... In P321, one dataset might be indexed one way (eg. h k l), the other might be index the other way (k h -l). When you compared this two dataset, they will appear to be different, because both indexing schemes, although valid, are not equivalent. Take one reflection; e.g. 3 2 1 from your crystal A. The very same reflection will be indexed 2 3 -1 for your crystal B, and the one indexed 3 2 1 for crytal B will not be equivalent to the 3 2 1 reflection from crystal A. If you try to merge your two datasets, you will have huge Rmerge, because you are trying to average non equivalent reflections. You will have to ensure that the same indexing scheme is used for both datasets, eg reindex B using the reindex k h -l command in reindex, before being able to merge A and B. hope this helps... please feel free to as if I am not clear... best regards laurent Le 29/05/2012 16:03, Qixu Cai a écrit :
Re: [ccp4bb] P321 space group reindex problem
Why the 29% Rfactor indicate the derivatives are not isomorphous to native dataset? Native dataset cell constant: 181.39 181.39 110.217 90 90 120 derivative1 cell constant: 181.909 181.909 109.62 90 90 120Rfactor to native: 26% derivative2 cell constant: 181.527 181.527 109.32 90 90 120Rfactor to native: 29% The Rfactor at low resolution is larger than in high resolution. Could you please to help me figure out where the heavy atoms had been soaked into the crystal? Thank you very much. Best wishe, Qixu Cai 2012/5/30 Laurent Maveyraud laurent.maveyr...@ipbs.fr Hi, it is therefore likely that your spacegroup is really P321... hopefully, your data set is not twinned, did you check that ? You are left with 2 possible indexing schemes, as already mentionned. Chek scaling derivative / native scaling for each indexation of the derivative : the lowest Rfactor will likely indicate the right one. It appears that you end up with Rfactor of about 29 %, which suggest that your derivatives are not isomorphous to your native dataset. How do cell parameters compare for each data set ? Check also how the Rfactor varies with resolution, you might still have usefull phasing info at low resolution. hope this helps laurent Le 30/05/2012 07:50, Qixu Cai a écrit : At first, I processed the data at P3 space group. But after phenix.xtriage analysis, the Xtriage told me the space group must be P321, so I used P321 to process my data, and got an acceptable Rmerge. Qixu Cai 2012/5/29 Phil Evans p...@mrc-lmb.cam.ac.uk mailto:p...@mrc-lmb.cam.ac.uk ** How do you know the point group is 321? What does Pointless tell you if you put in the unmerged data? Despite some of the things said earlier (by me!), the possible indexing schemes in 321 are h,k,l and -h,-k,l If that doesn't work, it suggests that the point group is a lower symmetry eg P3 Phil On 29 May 2012, at 16:29, Qixu Cai wrote: Dear all, thank you for your help. I think I must describe my case in detail. I collected a native dataset and two heavy atom derivant datasets （in fact, i don not know whether these two kind of heavy atom have soked into the crystal, i just collect the data to check it）. i processed all of three datasets with automar, and merged them by CAD. I used scaleit to get the Rfactor between datasets and got a strange result. the R factor between derivant1 and native is 26% and the R factor between derivant2 and native is 59%! so I think it may be the problem of index （space group is P321）. so i exchange the h and k of derivant2 by the some awk script and merged to native data by CAD. After scaleit analysis, I got the R factor 29% between derivant2 and native. Here is my questions, 1, at my case, is that right to invert the hand? is that the special problem of the P3 or p321 space group? 2, I have carryed out some suggestion of yours, such as use pointless （use native data as reference for derivant2 reindex）, or reindex the derivant2 dataset by （k, h, -l）, and I always got the high R factor 59% between derivant2 and native. Any suggestion? thanks a lot! Qixu Cai 在 2012-5-29，下午10:36，Laurent Maveyraud laurent.maveyr...@ipbs.fr mailto:laurent.maveyraud@**ipbs.frlaurent.maveyr...@ipbs.fr 写道： Hi... and apologies ! I was a little quick in my answer... in P321, h k l and -h -k l are valid indexing schemes... It is in P3 that you can have h k l and k h -l as Ian and Phil agreed on the BB ! sorry, laurent Hi, you might have several possible spacegroups possible when processing your data (at the indexation step). These will be based on the metrics of your cell (vector length and angles). If you happen to have something like a = b, and alpha=beta90° and gamma=120°, then it is likely that your crystal is trigonal or hexagonal. You will have to wait until the scaling step (or pointless after integration) in order to decide which spacegroup is the right one, based on the symmetry operations in your dataset and on systematic absences. There you have to choose between P3, P31, P32, P312, P321 in trigonal. When comparing two datasets from trigonal crystals, even for identical crystals and hence identical spacegroups, you have different ways to index your dataset... In P321, one dataset might be indexed one way (eg. h k l), the other might be index the other way (k h -l). When you compared this two dataset, they will appear to be different, because both indexing schemes, although valid, are not equivalent. Take one reflection; e.g. 3 2 1 from your crystal A. The very same
Re: [ccp4bb] P321 space group reindex problem
Thank you for your remind of the twin problem. I checked all of the datasets by Xtriage, and found that the native is not twinned, but the derivant1 and derivant2 are both twinned. So is the Rfactor between derivants and native useful for the judgement of the success of the heavy atom soaking? Thanks. Best wishes, Qixu Cai 2012/5/30 Laurent Maveyraud laurent.maveyr...@ipbs.fr Hi, it is therefore likely that your spacegroup is really P321... hopefully, your data set is not twinned, did you check that ? You are left with 2 possible indexing schemes, as already mentionned. Chek scaling derivative / native scaling for each indexation of the derivative : the lowest Rfactor will likely indicate the right one. It appears that you end up with Rfactor of about 29 %, which suggest that your derivatives are not isomorphous to your native dataset. How do cell parameters compare for each data set ? Check also how the Rfactor varies with resolution, you might still have usefull phasing info at low resolution. hope this helps laurent Le 30/05/2012 07:50, Qixu Cai a écrit : At first, I processed the data at P3 space group. But after phenix.xtriage analysis, the Xtriage told me the space group must be P321, so I used P321 to process my data, and got an acceptable Rmerge. Qixu Cai 2012/5/29 Phil Evans p...@mrc-lmb.cam.ac.uk mailto:p...@mrc-lmb.cam.ac.uk ** How do you know the point group is 321? What does Pointless tell you if you put in the unmerged data? Despite some of the things said earlier (by me!), the possible indexing schemes in 321 are h,k,l and -h,-k,l If that doesn't work, it suggests that the point group is a lower symmetry eg P3 Phil On 29 May 2012, at 16:29, Qixu Cai wrote: Dear all, thank you for your help. I think I must describe my case in detail. I collected a native dataset and two heavy atom derivant datasets （in fact, i don not know whether these two kind of heavy atom have soked into the crystal, i just collect the data to check it）. i processed all of three datasets with automar, and merged them by CAD. I used scaleit to get the Rfactor between datasets and got a strange result. the R factor between derivant1 and native is 26% and the R factor between derivant2 and native is 59%! so I think it may be the problem of index （space group is P321）. so i exchange the h and k of derivant2 by the some awk script and merged to native data by CAD. After scaleit analysis, I got the R factor 29% between derivant2 and native. Here is my questions, 1, at my case, is that right to invert the hand? is that the special problem of the P3 or p321 space group? 2, I have carryed out some suggestion of yours, such as use pointless （use native data as reference for derivant2 reindex）, or reindex the derivant2 dataset by （k, h, -l）, and I always got the high R factor 59% between derivant2 and native. Any suggestion? thanks a lot! Qixu Cai 在 2012-5-29，下午10:36，Laurent Maveyraud laurent.maveyr...@ipbs.fr mailto:laurent.maveyraud@**ipbs.frlaurent.maveyr...@ipbs.fr 写道： Hi... and apologies ! I was a little quick in my answer... in P321, h k l and -h -k l are valid indexing schemes... It is in P3 that you can have h k l and k h -l as Ian and Phil agreed on the BB ! sorry, laurent Hi, you might have several possible spacegroups possible when processing your data (at the indexation step). These will be based on the metrics of your cell (vector length and angles). If you happen to have something like a = b, and alpha=beta90° and gamma=120°, then it is likely that your crystal is trigonal or hexagonal. You will have to wait until the scaling step (or pointless after integration) in order to decide which spacegroup is the right one, based on the symmetry operations in your dataset and on systematic absences. There you have to choose between P3, P31, P32, P312, P321 in trigonal. When comparing two datasets from trigonal crystals, even for identical crystals and hence identical spacegroups, you have different ways to index your dataset... In P321, one dataset might be indexed one way (eg. h k l), the other might be index the other way (k h -l). When you compared this two dataset, they will appear to be different, because both indexing schemes, although valid, are not equivalent. Take one reflection; e.g. 3 2 1 from your crystal A. The very same reflection will be indexed 2 3 -1 for your crystal B, and the one indexed 3 2 1 for crytal B will not be equivalent to the 3 2 1 reflection from crystal A. If you try to merge your two datasets, you will have huge
Re: [ccp4bb] P321 space group reindex problem
Hi, Le 30/05/2012 08:29, Qixu Cai a écrit : Thank you for your remind of the twin problem. It is always a pleasure to be helpful ;-) By the way, you stated the spacegoup is P321... did you check systematic absences ? could it be P3121 / P3221 ? I checked all of the datasets by Xtriage, and found that the native is not twinned, but the derivant1 and derivant2 are both twinned. So is the Rfactor between derivants and native useful for the judgement of the success of the heavy atom soaking? Well, the unhelpful answer will be : it depends what is your twin fraction ? how does the scaling derivative/native perfom (in details... not only global Rfactors) Did you try to calculate Patterson maps (isomorphous and anomalous) ? I would try to find a good MIR tutorial (CCP4 website might be a good place to look at, but have a look at phenix website...), and try to adapt it to your specific case... good luck ! laurent Thanks. Best wishes, Qixu Cai 2012/5/30 Laurent Maveyraud laurent.maveyr...@ipbs.fr mailto:laurent.maveyr...@ipbs.fr Hi, it is therefore likely that your spacegroup is really P321... hopefully, your data set is not twinned, did you check that ? You are left with 2 possible indexing schemes, as already mentionned. Chek scaling derivative / native scaling for each indexation of the derivative : the lowest Rfactor will likely indicate the right one. It appears that you end up with Rfactor of about 29 %, which suggest that your derivatives are not isomorphous to your native dataset. How do cell parameters compare for each data set ? Check also how the Rfactor varies with resolution, you might still have usefull phasing info at low resolution. hope this helps laurent Le 30/05/2012 07:50, Qixu Cai a écrit : At first, I processed the data at P3 space group. But after phenix.xtriage analysis, the Xtriage told me the space group must be P321, so I used P321 to process my data, and got an acceptable Rmerge. Qixu Cai 2012/5/29 Phil Evans p...@mrc-lmb.cam.ac.uk mailto:p...@mrc-lmb.cam.ac.uk mailto:p...@mrc-lmb.cam.ac.uk mailto:p...@mrc-lmb.cam.ac.uk__ How do you know the point group is 321? What does Pointless tell you if you put in the unmerged data? Despite some of the things said earlier (by me!), the possible indexing schemes in 321 are h,k,l and -h,-k,l If that doesn't work, it suggests that the point group is a lower symmetry eg P3 Phil On 29 May 2012, at 16:29, Qixu Cai wrote: Dear all, thank you for your help. I think I must describe my case in detail. I collected a native dataset and two heavy atom derivant datasets （in fact, i don not know whether these two kind of heavy atom have soked into the crystal, i just collect the data to check it）. i processed all of three datasets with automar, and merged them by CAD. I used scaleit to get the Rfactor between datasets and got a strange result. the R factor between derivant1 and native is 26% and the R factor between derivant2 and native is 59%! so I think it may be the problem of index （space group is P321）. so i exchange the h and k of derivant2 by the some awk script and merged to native data by CAD. After scaleit analysis, I got the R factor 29% between derivant2 and native. Here is my questions, 1, at my case, is that right to invert the hand? is that the special problem of the P3 or p321 space group? 2, I have carryed out some suggestion of yours, such as use pointless （use native data as reference for derivant2 reindex）, or reindex the derivant2 dataset by （k, h, -l）, and I always got the high R factor 59% between derivant2 and native. Any suggestion? thanks a lot! Qixu Cai 在 2012-5-29，下午10:36，Laurent Maveyraud laurent.maveyr...@ipbs.fr mailto:laurent.maveyr...@ipbs.fr mailto:laurent.maveyraud@__ipbs.fr mailto:laurent.maveyr...@ipbs.fr 写道： Hi... and apologies ! I was a little quick in my answer... in P321, h k l and -h -k l are valid indexing schemes... It is in P3 that you can have h k l and k h -l as Ian and Phil agreed on the BB ! sorry, laurent Hi, you might have several possible spacegroups possible when processing your data (at the indexation step).
Re: [ccp4bb] P321 space group reindex problem
Hi there, I am not certain that the thread is P321 space group reindex problem any more. But: trigonal (and hexagonal) space groups are (usually?) polar. The cell axis c can go up or can go down, and in order to get a consistent indexing you need to check both indexing systems when you scale additional data to your native (the indexing chosen by your first crystals defines the standard indexing - I must say that I haven't checked in the drawings of the international tables if having c going up or going down leads to a difference in that particular space group, P321, I'd need to draw both possibilities and check but I'm sorry I do not have the time right now - in fact it's too bad that the International Tables do not indicate Polar or Non-polar). For practical purposes, a derivative is considered non isomorphous when the differences in unit cell parameters exceed ca. 1% (this is because if you take 2 crystals from the same crystallisation drop and collect and process diffraction crystals from these 2 crystals, you will never get exactly the very same values for the unit cell parameters; non-isomorphism effects start at ca. 1% change and you'll never get 2 perfectly isomorphous crystals - even if you collect diffraction data twice from the same crystals you will not get perfect isomorphism). From the values mentioned, 1% of the cell parameters of the native for a and b is 1.81 Angstroem and for c 1.1 Angstroem (the angles do not matter for a trigonal space group). Had you obtained a value for a, b larger than ca. 183 Angstroem, or below ca. 109.2 Angstroem (only in the direction indicated by the changes mentioned in your mail - I ignored changes in the opposite direction) then you would have been able to say that the crystals were non-isomorphous to each other. For me they are isomorphous to each other and I ignore these small differences in unit cell parameters. The difference of 3% in Rfactor (I suppose this is |FP - FPH| / |FP|, no Sigma character on my keyboard to indicate the summations over h k l) is I think due to 2 different chemicals (heavy-atom compounds) in derivative 1 and derivative 2. Differences in R-factors at low resolutions are often associated with solvent effects, and I think you will have 2 different mother liquors and hence 2 different solvents in derivative 1 and in derivative 2. That is assuming that derivative 1 and derivative 2 were prepared using 2 different chemicals. And typically low-resolution data (below 15 Angstroem resolution or so) is kept out during phasing by the MIR method. To locate the heavy atom constellations in the 2 derivatives, you could compute and interpret difference Patterson maps - including automated interpretation, vector search and the likes -, you could use direct methods (the heavy atom constellation is similar to a small molecule because there are far fewer atoms there than in the full macromolecule, and direct methods work extremely well for small molecules - you would need to use the isomorphous differences in order to use direct methods; no mention is made of any anomalous signal so I do not know if you could this as well). HTH, Fred. Qixu Cai wrote: Why the 29% Rfactor indicate the derivatives are not isomorphous to native dataset? Native dataset cell constant: 181.39 181.39 110.217 90 90 120 derivative1 cell constant: 181.909 181.909 109.62 90 90 120Rfactor to native: 26% derivative2 cell constant: 181.527 181.527 109.32 90 90 120Rfactor to native: 29% The Rfactor at low resolution is larger than in high resolution. Could you please to help me figure out where the heavy atoms had been soaked into the crystal? Thank you very much. Best wishe, Qixu Cai 2012/5/30 Laurent Maveyraud laurent.maveyr...@ipbs.fr mailto:laurent.maveyr...@ipbs.fr Hi, it is therefore likely that your spacegroup is really P321... hopefully, your data set is not twinned, did you check that ? You are left with 2 possible indexing schemes, as already mentionned. Chek scaling derivative / native scaling for each indexation of the derivative : the lowest Rfactor will likely indicate the right one. It appears that you end up with Rfactor of about 29 %, which suggest that your derivatives are not isomorphous to your native dataset. How do cell parameters compare for each data set ? Check also how the Rfactor varies with resolution, you might still have usefull phasing info at low resolution. hope this helps laurent Le 30/05/2012 07:50, Qixu Cai a écrit : At first, I processed the data at P3 space group. But after phenix.xtriage analysis, the Xtriage told me the space group must be P321, so I used P321 to process my data, and got an acceptable Rmerge. Qixu Cai 2012/5/29 Phil Evans p...@mrc-lmb.cam.ac.uk mailto:p...@mrc-lmb.cam.ac.uk
Re: [ccp4bb] P321 space group reindex problem
If the data sets are twinned, large differences between derivatives are to be expected unless the twin fraction is very, very low (1-2%). Given the above, I think nothing can be said until the data are all detwinned - and of course the correct axial interchange done. Adrian On 30 May 2012, at 09:55, Vellieux Frederic wrote: Hi there, I am not certain that the thread is P321 space group reindex problem any more. But: trigonal (and hexagonal) space groups are (usually?) polar. The cell axis c can go up or can go down, and in order to get a consistent indexing you need to check both indexing systems when you scale additional data to your native (the indexing chosen by your first crystals defines the standard indexing - I must say that I haven't checked in the drawings of the international tables if having c going up or going down leads to a difference in that particular space group, P321, I'd need to draw both possibilities and check but I'm sorry I do not have the time right now - in fact it's too bad that the International Tables do not indicate Polar or Non-polar). For practical purposes, a derivative is considered non isomorphous when the differences in unit cell parameters exceed ca. 1% (this is because if you take 2 crystals from the same crystallisation drop and collect and process diffraction crystals from these 2 crystals, you will never get exactly the very same values for the unit cell parameters; non-isomorphism effects start at ca. 1% change and you'll never get 2 perfectly isomorphous crystals - even if you collect diffraction data twice from the same crystals you will not get perfect isomorphism). From the values mentioned, 1% of the cell parameters of the native for a and b is 1.81 Angstroem and for c 1.1 Angstroem (the angles do not matter for a trigonal space group). Had you obtained a value for a, b larger than ca. 183 Angstroem, or below ca. 109.2 Angstroem (only in the direction indicated by the changes mentioned in your mail - I ignored changes in the opposite direction) then you would have been able to say that the crystals were non-isomorphous to each other. For me they are isomorphous to each other and I ignore these small differences in unit cell parameters. The difference of 3% in Rfactor (I suppose this is |FP - FPH| / |FP|, no Sigma character on my keyboard to indicate the summations over h k l) is I think due to 2 different chemicals (heavy-atom compounds) in derivative 1 and derivative 2. Differences in R-factors at low resolutions are often associated with solvent effects, and I think you will have 2 different mother liquors and hence 2 different solvents in derivative 1 and in derivative 2. That is assuming that derivative 1 and derivative 2 were prepared using 2 different chemicals. And typically low-resolution data (below 15 Angstroem resolution or so) is kept out during phasing by the MIR method. To locate the heavy atom constellations in the 2 derivatives, you could compute and interpret difference Patterson maps - including automated interpretation, vector search and the likes -, you could use direct methods (the heavy atom constellation is similar to a small molecule because there are far fewer atoms there than in the full macromolecule, and direct methods work extremely well for small molecules - you would need to use the isomorphous differences in order to use direct methods; no mention is made of any anomalous signal so I do not know if you could this as well). HTH, Fred. Qixu Cai wrote: Why the 29% Rfactor indicate the derivatives are not isomorphous to native dataset? Native dataset cell constant: 181.39 181.39 110.217 90 90 120 derivative1 cell constant: 181.909 181.909 109.62 90 90 120 Rfactor to native: 26% derivative2 cell constant: 181.527 181.527 109.32 90 90 120 Rfactor to native: 29% The Rfactor at low resolution is larger than in high resolution. Could you please to help me figure out where the heavy atoms had been soaked into the crystal? Thank you very much. Best wishe, Qixu Cai 2012/5/30 Laurent Maveyraud laurent.maveyr...@ipbs.fr mailto:laurent.maveyr...@ipbs.fr Hi, it is therefore likely that your spacegroup is really P321... hopefully, your data set is not twinned, did you check that ? You are left with 2 possible indexing schemes, as already mentionned. Chek scaling derivative / native scaling for each indexation of the derivative : the lowest Rfactor will likely indicate the right one. It appears that you end up with Rfactor of about 29 %, which suggest that your derivatives are not isomorphous to your native dataset. How do cell parameters compare for each data set ? Check also how the Rfactor varies with resolution, you might still have usefull phasing info at low resolution. hope this helps
Re: [ccp4bb] P321 space group reindex problem
Hi Fred, On Wed, May 30, 2012 at 08:55:35AM +0200, Vellieux Frederic wrote: For practical purposes, a derivative is considered non isomorphous when the differences in unit cell parameters exceed ca. 1% (this is because if you take 2 crystals from the same crystallisation drop and collect and process diffraction crystals from these 2 crystals, you will never get exactly the very same values for the unit cell parameters; non-isomorphism effects start at ca. 1% change and you'll never get 2 perfectly isomorphous crystals - even if you collect diffraction data twice from the same crystals you will not get perfect isomorphism). From the values mentioned, 1% of the cell parameters of the native for a and b is 1.81 Angstroem and for c 1.1 Angstroem (the angles do not matter for a trigonal space group). Had you obtained a value for a, b larger than ca. 183 Angstroem, or below ca. 109.2 Angstroem (only in the direction indicated by the changes mentioned in your mail - I ignored changes in the opposite direction) then you would have been able to say that the crystals were non-isomorphous to each other. For me they are isomorphous to each other and I ignore these small differences in unit cell parameters. I would be careful with the (popular) percentage-rule here: the absolute value of cell differences is much more important. At least if we assume that the change in cell parameters roughly corresponds with a shift in actual atoms. If you have a 1000A cell then a 1% difference could mean a shift of 10A ... clearly, a helix moved 10A away results in something completely different. But with a cell of 20A you could have a 0.2A shift, which you might hardly notice. See eg. 5.2 in Garman Murray (2003): http://journals.iucr.org/d/issues/2003/11/00/ba5042/index.html which shows 5.2. Non-isomorphism One of the biggest problems of heavy-atom derivatization is that incorporation of a heavy atom into the lattice often induces a change in the unit cell away from the native crystal values, i.e. the derivatized crystal is non-isomorphous to the native crystals. The heavy atom may perturb the arrangement of protein molecules in the crystal or distort the protein molecule, causing a change in unit-cell lengths. Note, however, that it is also possible for the protein to move within the original unit cell (resulting in a different sampling of the molecular transform). The same unit cell is thus a necessary but not sufficient condition for isomorphism. Crick Magdoff (1956[Crick, F. H. C. Magdoff, B. S. (1956). Acta Cryst. 9, 901-908.]) calculated that a 0.5 Å change in all three unit-cell edges of a 100 Å cubed unit cell would change the diffraction intensities by an average of 15% in a 3 Å resolution sphere. The predicted intensity changes induced by non-isomorphism increase at higher resolution. When faced with a non-isomorphous derivative, it is the absolute change in the cell which should be considered compared with the working resolution, rather than the relative change, i.e. a change of 1.0% in a 100 Å unit cell edge has a similar effect to that of a 0.5% change in a 200 Å unit cell edge, if compared at similar resolutions. As a general rule of thumb, a change in cell dimensions of dmin/4 is tolerable, where dmin is the resolution limit (Drenth, 1999[Drenth, J. (1999). Principles of Protein X-ray Crystallography, 2nd ed. Berlin: Springer-Verlag.]). For instance, for 2.5 Å data, a 0.6 Å change in the unit cell might be acceptable, whereas at 3.5 Å this could rise to 0.8 Å. 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] P321 space group reindex problem
Hello Fred On 30 May 2012 07:55, Vellieux Frederic frederic.velli...@ibs.fr wrote: Hi there, But: trigonal (and hexagonal) space groups are (usually?) polar. The cell axis c can go up or can go down, and in order to get a consistent indexing you need to check both indexing systems when you scale additional data to your native (the indexing chosen by your first crystals defines the standard indexing - I must say that I haven't checked in the drawings of the international tables if having c going up or going down leads to a difference in that particular space group, P321, I'd need to draw both possibilities and check but I'm sorry I do not have the time right now - in fact it's too bad that the International Tables do not indicate Polar or Non-polar). It does, at least my edition (Vol. A: 5th ed., 2002, Table 10.2.1.2, p.806) does - ITC has everything you need to know about space groups (and a lot more besides)! See also this table that I made where all polar non-polar SGs are listed individually: http://www.ccp4.ac.uk/dist/html/alternate_origins.html Counting only the non-enantiomorphic ones, PG3 (4 SGs) and PG6 (6 SGs) are polar, whereas PG321 (3 SGs), PG312 (3 SGs), PG32 (1 SG) and PG622 (6 SGs) are non-polar. So in all 10 are polar and 13 are non-polar. A 2-fold axis perp to another axis always implies that there's no preferred direction along the other axis, so it's non-polar. Cheers -- Ian
Re: [ccp4bb] P321 space group reindex problem
Hi Ian, You're right the information is there... but not where I was expecting it (on the page corresponding to an individual space group). It had never occurred to me that it could be somewhere else. So thanks, and regards to Jasmine. Fred. Ian Tickle wrote: Hello Fred On 30 May 2012 07:55, Vellieux Frederic frederic.velli...@ibs.fr wrote: Hi there, But: trigonal (and hexagonal) space groups are (usually?) polar. The cell axis c can go up or can go down, and in order to get a consistent indexing you need to check both indexing systems when you scale additional data to your native (the indexing chosen by your first crystals defines the standard indexing - I must say that I haven't checked in the drawings of the international tables if having c going up or going down leads to a difference in that particular space group, P321, I'd need to draw both possibilities and check but I'm sorry I do not have the time right now - in fact it's too bad that the International Tables do not indicate Polar or Non-polar). It does, at least my edition (Vol. A: 5th ed., 2002, Table 10.2.1.2, p.806) does - ITC has everything you need to know about space groups (and a lot more besides)! See also this table that I made where all polar non-polar SGs are listed individually: http://www.ccp4.ac.uk/dist/html/alternate_origins.html Counting only the non-enantiomorphic ones, PG3 (4 SGs) and PG6 (6 SGs) are polar, whereas PG321 (3 SGs), PG312 (3 SGs), PG32 (1 SG) and PG622 (6 SGs) are non-polar. So in all 10 are polar and 13 are non-polar. A 2-fold axis perp to another axis always implies that there's no preferred direction along the other axis, so it's non-polar. Cheers -- Ian
Re: [ccp4bb] P321 space group reindex problem
It does, at least my edition (Vol. A: 5th ed., 2002, Table 10.2.1.2, p.806) does - ITC has everything you need to know about space groups (and a lot more besides)! Actually, as the aforementioned table indicates, it's not correct to talk about polar and non-polar space groups, but only about polar and non-polar directions in space groups. Many space-groups have both polar and non-polar directions, which would seem to imply that these space groups are both polar and non-polar at the same time!!! For example, P3 has a polar direction parallel to the 3-fold and no non-polar directions, whereas P321, even though it's classed as a non-polar space group, nevertheless has 3 polar directions [100], [010], [-1-10] parallel to the 3 2-folds in the xy plane, plus 4 non-polar directions (including the 3-fold). Note that any direction perpendicular to an even-fold rotation axis is always non-polar: these 'trivial' cases are not shown explicitly in the above table. From the point of view of deciding which are the alternate settings I don't think it's helpful to consider polar directions anyway. What matters is which symmetry axes of the lattice are not present in the point group. So in the case of P321 the hexagonal lattice has a 6-fold parallel to c which can be thought of as the product of a 3- and a 2-fold both || c, and also 2-folds perp to the 6-fold. The 3-fold and the perp 2-folds are all present in P321 but the 2-fold || c is not, so that is what gives rise to the 2 alternate settings (h,k,l) and (-h,-k,l). In P3 all 2-folds are missing so you get 4 alternate settings. The same missing symmetry can also give rise to merohedral twinning, so it's nice to kill 2 birds with 1 stone! Cheers -- Ian
Re: [ccp4bb] P321 space group reindex problem
On Wed, 30 May 2012 13:16:12 +0100 Ian Tickle ianj...@gmail.com wrote: From the point of view of deciding which are the alternate settings I don't think it's helpful to consider polar directions anyway. What matters is which symmetry axes of the lattice are not present in the point group. Possibly relevant here is a set of tables I put together for our free-electron laser experiments, where tens or even hundreds of thousands of patterns have to be indexed independently: https://www.desy.de/~twhite/crystfel/twin-calculator.pdf Underlying these tables is the same underlying information as everything else mentioned on this thread, but these ones tell you what the apparent symmetry would be if the intensities were mixed up according to all the available indexing ambiguities. So far, no-one has been able to reliably resolve these ambiguities in our case: the intensities are just obscured by too much noise, partiality, a spiky X-ray spectrum and so on. That's why we have to have so many patterns. For the time being, we just merge according to the higher symmetry, accept that the data may be (perfectly) twinned, and handle it at the later stages. Later on when we've hopefully solved this problem, these tables will serve as a menu of options for doing the whole thing backwards. I agree that polarity isn't the right criterion. Point group 2 is polar but does not exhibit any indexing ambiguity. Point group 4/m, which is most definitely not polar, does. This paper, Le Page et al., has some similar tables but lists the actual ambiguity operators: http://scripts.iucr.org/cgi-bin/paper?S0108767384001392 Of course, all of this only covers merohedral ambiguities, not pseudo-merohedral ones which might arise by accident in special cases. Comments on and corrections to the tables are welcome! Tom
[ccp4bb] P321 space group reindex problem
Dear all, I have a dataset at P321 space group. And I want to reindex from (h,k,l) to (k,h,l) or (h,k,-l), because I want to merge this dataset to the native dataset. At first, I used the reindex program in CCP4i, and got an error: (either for (k,h,l) or (h,k,-l)) Data line--- reindex HKL h, k, -l Data line--- end $TEXT:Warning: $$ comment $$ WARNING: Reindexing matrix INVERTS hand $$ REINDEX: You are NOT allowed to do this - Changing all signs in reindexing matrix Times: User: 0.0s System:0.0s Elapsed: 0:00 = Could you please tell me the reason? At last, I converted the mtz file to CNS format, and write a script to exchange the h and k, and converted to mtz file. When I tried to use cad to merge this dataset to the native dataset, if I chose Automatically check and enforce consistent indexing between different files, the index would be changed back to the original index. Why? Thank you very much for your attention. Best wishes, Qixu Cai
Re: [ccp4bb] P321 space group reindex problem
In principle there's no reason why you can't invert the hand of the indices, as long as the program which does it also takes care to convert any hand-dependent columns such as anomalous differences, F+/F- etc in the appropriate manner at the same time. The program will also need to convert any phase or phase-coefficient columns, but it will have to do this anyway, even if the hand is not inverted, in those cases where the space group contains screw axes (since then you will get phase shifts on reindexing for certain subsets of reflections). So if the data consist only of I's or F's without anomalous data or phases then inverting the hand will have absolutely no effect (it's called Friedel's Law). I note from the documentation that reindex will invert the hand if the keyword 'LEFT' is supplied, though whether it then treats the anomalous data and phases correctly is anyone's guess! The question is really whether it's likely ever to be _necessary_ to invert the hand; this will depend on the reciprocal space asymmetric unit chosen by the processing program. One could imagine a situation where the a.u. chosen by one processing program was on a different hand from the a.u. required by another. In such a situation you would have no choice but to invert the hand of the indices, though I suspect you would be better off doing it with CAD which will do it reliably, rather than reindex which may not (judging by the comments in the reindex code!). Whether such a situation ever occurs in practice, I don't know, maybe not. Cheers -- Ian On 29 May 2012 09:57, Graeme Winter graeme.win...@gmail.com wrote: Hello Qixu Cai, What you want is a reindexing operator which permutes the axes rather than one which changes the sign of an axis. The easiest way to do this is with pointless: pointless hklin input.mtz hklref reference.mtz hklout output.mtz and let pointless figure out the right operation to use. You may find the following helpful: http://www.ccp4.ac.uk/html/reindexing.html Best wishes, Graeme On 29 May 2012 09:48, Qixu Cai caiq...@gmail.com wrote: Dear all, I have a dataset at P321 space group. And I want to reindex from (h,k,l) to (k,h,l) or (h,k,-l), because I want to merge this dataset to the native dataset. At first, I used the reindex program in CCP4i, and got an error: (either for (k,h,l) or (h,k,-l)) Data line--- reindex HKL h, k, -l Data line--- end $TEXT:Warning: $$ comment $$ WARNING: Reindexing matrix INVERTS hand $$ REINDEX: You are NOT allowed to do this - Changing all signs in reindexing matrix Times: User: 0.0s System: 0.0s Elapsed: 0:00 = Could you please tell me the reason? At last, I converted the mtz file to CNS format, and write a script to exchange the h and k, and converted to mtz file. When I tried to use cad to merge this dataset to the native dataset, if I chose Automatically check and enforce consistent indexing between different files, the index would be changed back to the original index. Why? Thank you very much for your attention. Best wishes, Qixu Cai
Re: [ccp4bb] P321 space group reindex problem
In different datasets of P321 crystals, when you index them separately, the hand may be different and you may need to invert it for some. They prohibition in reindex is really a warning, and can be overridden. Mark J van Raaij Laboratorio M-4 Dpto de Estructura de Macromoleculas Centro Nacional de Biotecnologia - CSIC c/Darwin 3 E-28049 Madrid, Spain tel. (+34) 91 585 4616 http://www.cnb.csic.es/~mjvanraaij On 29 May 2012, at 13:52, Ian Tickle wrote: In principle there's no reason why you can't invert the hand of the indices, as long as the program which does it also takes care to convert any hand-dependent columns such as anomalous differences, F+/F- etc in the appropriate manner at the same time. The program will also need to convert any phase or phase-coefficient columns, but it will have to do this anyway, even if the hand is not inverted, in those cases where the space group contains screw axes (since then you will get phase shifts on reindexing for certain subsets of reflections). So if the data consist only of I's or F's without anomalous data or phases then inverting the hand will have absolutely no effect (it's called Friedel's Law). I note from the documentation that reindex will invert the hand if the keyword 'LEFT' is supplied, though whether it then treats the anomalous data and phases correctly is anyone's guess! The question is really whether it's likely ever to be _necessary_ to invert the hand; this will depend on the reciprocal space asymmetric unit chosen by the processing program. One could imagine a situation where the a.u. chosen by one processing program was on a different hand from the a.u. required by another. In such a situation you would have no choice but to invert the hand of the indices, though I suspect you would be better off doing it with CAD which will do it reliably, rather than reindex which may not (judging by the comments in the reindex code!). Whether such a situation ever occurs in practice, I don't know, maybe not. Cheers -- Ian On 29 May 2012 09:57, Graeme Winter graeme.win...@gmail.com wrote: Hello Qixu Cai, What you want is a reindexing operator which permutes the axes rather than one which changes the sign of an axis. The easiest way to do this is with pointless: pointless hklin input.mtz hklref reference.mtz hklout output.mtz and let pointless figure out the right operation to use. You may find the following helpful: http://www.ccp4.ac.uk/html/reindexing.html Best wishes, Graeme On 29 May 2012 09:48, Qixu Cai caiq...@gmail.com wrote: Dear all, I have a dataset at P321 space group. And I want to reindex from (h,k,l) to (k,h,l) or (h,k,-l), because I want to merge this dataset to the native dataset. At first, I used the reindex program in CCP4i, and got an error: (either for (k,h,l) or (h,k,-l)) Data line--- reindex HKL h, k, -l Data line--- end $TEXT:Warning: $$ comment $$ WARNING: Reindexing matrix INVERTS hand $$ REINDEX: You are NOT allowed to do this - Changing all signs in reindexing matrix Times: User: 0.0s System:0.0s Elapsed: 0:00 = Could you please tell me the reason? At last, I converted the mtz file to CNS format, and write a script to exchange the h and k, and converted to mtz file. When I tried to use cad to merge this dataset to the native dataset, if I chose Automatically check and enforce consistent indexing between different files, the index would be changed back to the original index. Why? Thank you very much for your attention. Best wishes, Qixu Cai
Re: [ccp4bb] P321 space group reindex problem
Thanks for your help. How to use CAD to invert the hand? 2012/5/29 Ian Tickle ianj...@gmail.com In principle there's no reason why you can't invert the hand of the indices, as long as the program which does it also takes care to convert any hand-dependent columns such as anomalous differences, F+/F- etc in the appropriate manner at the same time. The program will also need to convert any phase or phase-coefficient columns, but it will have to do this anyway, even if the hand is not inverted, in those cases where the space group contains screw axes (since then you will get phase shifts on reindexing for certain subsets of reflections). So if the data consist only of I's or F's without anomalous data or phases then inverting the hand will have absolutely no effect (it's called Friedel's Law). I note from the documentation that reindex will invert the hand if the keyword 'LEFT' is supplied, though whether it then treats the anomalous data and phases correctly is anyone's guess! The question is really whether it's likely ever to be _necessary_ to invert the hand; this will depend on the reciprocal space asymmetric unit chosen by the processing program. One could imagine a situation where the a.u. chosen by one processing program was on a different hand from the a.u. required by another. In such a situation you would have no choice but to invert the hand of the indices, though I suspect you would be better off doing it with CAD which will do it reliably, rather than reindex which may not (judging by the comments in the reindex code!). Whether such a situation ever occurs in practice, I don't know, maybe not. Cheers -- Ian On 29 May 2012 09:57, Graeme Winter graeme.win...@gmail.com wrote: Hello Qixu Cai, What you want is a reindexing operator which permutes the axes rather than one which changes the sign of an axis. The easiest way to do this is with pointless: pointless hklin input.mtz hklref reference.mtz hklout output.mtz and let pointless figure out the right operation to use. You may find the following helpful: http://www.ccp4.ac.uk/html/reindexing.html Best wishes, Graeme On 29 May 2012 09:48, Qixu Cai caiq...@gmail.com wrote: Dear all, I have a dataset at P321 space group. And I want to reindex from (h,k,l) to (k,h,l) or (h,k,-l), because I want to merge this dataset to the native dataset. At first, I used the reindex program in CCP4i, and got an error: (either for (k,h,l) or (h,k,-l)) Data line--- reindex HKL h, k, -l Data line--- end $TEXT:Warning: $$ comment $$ WARNING: Reindexing matrix INVERTS hand $$ REINDEX: You are NOT allowed to do this - Changing all signs in reindexing matrix Times: User: 0.0s System:0.0s Elapsed: 0:00 = Could you please tell me the reason? At last, I converted the mtz file to CNS format, and write a script to exchange the h and k, and converted to mtz file. When I tried to use cad to merge this dataset to the native dataset, if I chose Automatically check and enforce consistent indexing between different files, the index would be changed back to the original index. Why? Thank you very much for your attention. Best wishes, Qixu Cai
Re: [ccp4bb] P321 space group reindex problem
Thanks for your help. How to override the warning? 2012/5/29 Mark J van Raaij mjvanra...@cnb.csic.es In different datasets of P321 crystals, when you index them separately, the hand may be different and you may need to invert it for some. They prohibition in reindex is really a warning, and can be overridden. Mark J van Raaij Laboratorio M-4 Dpto de Estructura de Macromoleculas Centro Nacional de Biotecnologia - CSIC c/Darwin 3 E-28049 Madrid, Spain tel. (+34) 91 585 4616 http://www.cnb.csic.es/~mjvanraaij On 29 May 2012, at 13:52, Ian Tickle wrote: In principle there's no reason why you can't invert the hand of the indices, as long as the program which does it also takes care to convert any hand-dependent columns such as anomalous differences, F+/F- etc in the appropriate manner at the same time. The program will also need to convert any phase or phase-coefficient columns, but it will have to do this anyway, even if the hand is not inverted, in those cases where the space group contains screw axes (since then you will get phase shifts on reindexing for certain subsets of reflections). So if the data consist only of I's or F's without anomalous data or phases then inverting the hand will have absolutely no effect (it's called Friedel's Law). I note from the documentation that reindex will invert the hand if the keyword 'LEFT' is supplied, though whether it then treats the anomalous data and phases correctly is anyone's guess! The question is really whether it's likely ever to be _necessary_ to invert the hand; this will depend on the reciprocal space asymmetric unit chosen by the processing program. One could imagine a situation where the a.u. chosen by one processing program was on a different hand from the a.u. required by another. In such a situation you would have no choice but to invert the hand of the indices, though I suspect you would be better off doing it with CAD which will do it reliably, rather than reindex which may not (judging by the comments in the reindex code!). Whether such a situation ever occurs in practice, I don't know, maybe not. Cheers -- Ian On 29 May 2012 09:57, Graeme Winter graeme.win...@gmail.com wrote: Hello Qixu Cai, What you want is a reindexing operator which permutes the axes rather than one which changes the sign of an axis. The easiest way to do this is with pointless: pointless hklin input.mtz hklref reference.mtz hklout output.mtz and let pointless figure out the right operation to use. You may find the following helpful: http://www.ccp4.ac.uk/html/reindexing.html Best wishes, Graeme On 29 May 2012 09:48, Qixu Cai caiq...@gmail.com wrote: Dear all, I have a dataset at P321 space group. And I want to reindex from (h,k,l) to (k,h,l) or (h,k,-l), because I want to merge this dataset to the native dataset. At first, I used the reindex program in CCP4i, and got an error: (either for (k,h,l) or (h,k,-l)) Data line--- reindex HKL h, k, -l Data line--- end $TEXT:Warning: $$ comment $$ WARNING: Reindexing matrix INVERTS hand $$ REINDEX: You are NOT allowed to do this - Changing all signs in reindexing matrix Times: User: 0.0s System:0.0s Elapsed: 0:00 = Could you please tell me the reason? At last, I converted the mtz file to CNS format, and write a script to exchange the h and k, and converted to mtz file. When I tried to use cad to merge this dataset to the native dataset, if I chose Automatically check and enforce consistent indexing between different files, the index would be changed back to the original index. Why? Thank you very much for your attention. Best wishes, Qixu Cai
Re: [ccp4bb] P321 space group reindex problem
NO do NOT invert the hand. If you do you will end up with left-handed helices etc The alternative indexing systems all need to preserve the right-handed axis system imposed by the data integration program (eg k,h,-l) The ONLY time it is valid to invert the hand is if the indexing/integration program itself inverted the hand due to a bug (this has been know, but not for a long time) Phil On 29 May 2012, at 12:55, Mark J van Raaij wrote: In different datasets of P321 crystals, when you index them separately, the hand may be different and you may need to invert it for some. They prohibition in reindex is really a warning, and can be overridden. Mark J van Raaij Laboratorio M-4 Dpto de Estructura de Macromoleculas Centro Nacional de Biotecnologia - CSIC c/Darwin 3 E-28049 Madrid, Spain tel. (+34) 91 585 4616 http://www.cnb.csic.es/~mjvanraaij On 29 May 2012, at 13:52, Ian Tickle wrote: In principle there's no reason why you can't invert the hand of the indices, as long as the program which does it also takes care to convert any hand-dependent columns such as anomalous differences, F+/F- etc in the appropriate manner at the same time. The program will also need to convert any phase or phase-coefficient columns, but it will have to do this anyway, even if the hand is not inverted, in those cases where the space group contains screw axes (since then you will get phase shifts on reindexing for certain subsets of reflections). So if the data consist only of I's or F's without anomalous data or phases then inverting the hand will have absolutely no effect (it's called Friedel's Law). I note from the documentation that reindex will invert the hand if the keyword 'LEFT' is supplied, though whether it then treats the anomalous data and phases correctly is anyone's guess! The question is really whether it's likely ever to be _necessary_ to invert the hand; this will depend on the reciprocal space asymmetric unit chosen by the processing program. One could imagine a situation where the a.u. chosen by one processing program was on a different hand from the a.u. required by another. In such a situation you would have no choice but to invert the hand of the indices, though I suspect you would be better off doing it with CAD which will do it reliably, rather than reindex which may not (judging by the comments in the reindex code!). Whether such a situation ever occurs in practice, I don't know, maybe not. Cheers -- Ian On 29 May 2012 09:57, Graeme Winter graeme.win...@gmail.com wrote: Hello Qixu Cai, What you want is a reindexing operator which permutes the axes rather than one which changes the sign of an axis. The easiest way to do this is with pointless: pointless hklin input.mtz hklref reference.mtz hklout output.mtz and let pointless figure out the right operation to use. You may find the following helpful: http://www.ccp4.ac.uk/html/reindexing.html Best wishes, Graeme On 29 May 2012 09:48, Qixu Cai caiq...@gmail.com wrote: Dear all, I have a dataset at P321 space group. And I want to reindex from (h,k,l) to (k,h,l) or (h,k,-l), because I want to merge this dataset to the native dataset. At first, I used the reindex program in CCP4i, and got an error: (either for (k,h,l) or (h,k,-l)) Data line--- reindex HKL h, k, -l Data line--- end $TEXT:Warning: $$ comment $$ WARNING: Reindexing matrix INVERTS hand $$ REINDEX: You are NOT allowed to do this - Changing all signs in reindexing matrix Times: User: 0.0s System:0.0s Elapsed: 0:00 = Could you please tell me the reason? At last, I converted the mtz file to CNS format, and write a script to exchange the h and k, and converted to mtz file. When I tried to use cad to merge this dataset to the native dataset, if I chose Automatically check and enforce consistent indexing between different files, the index would be changed back to the original index. Why? Thank you very much for your attention. Best wishes, Qixu Cai
Re: [ccp4bb] P321 space group reindex problem
Mark, thanks for pointing that out, I see it now: In P321 the only possible alternate indexing is (-h, -k, l): this is a 2-fold || c which is an operator of the hexagonal lattice but is not an equivalent reflection. The standard CCP4 a.u. is h = k, l = 0 or h k, k = 0, so for example (3,2,1) would be in the standard a.u. (3 2 and 2 = 0). In the alternate indexing this would be (-3, -2, 1); however it's impossible to transform this to the a.u. with any non-inverting equivalent. The only possibility is to invert the hand, i.e. to (3, 2, -1) which is again in the a.u.. So the required re-indexing operator to match (3, 2, -1) with (3, 2, 1) is (h, k, -l) which reindex won't allow without the LEFT keyword (and you would be well-advised to avoid doing it with phase columns!). Cheers -- Ian On 29 May 2012 12:55, Mark J van Raaij mjvanra...@cnb.csic.es wrote: In different datasets of P321 crystals, when you index them separately, the hand may be different and you may need to invert it for some. They prohibition in reindex is really a warning, and can be overridden. Mark J van Raaij Laboratorio M-4 Dpto de Estructura de Macromoleculas Centro Nacional de Biotecnologia - CSIC c/Darwin 3 E-28049 Madrid, Spain tel. (+34) 91 585 4616 http://www.cnb.csic.es/~mjvanraaij On 29 May 2012, at 13:52, Ian Tickle wrote: In principle there's no reason why you can't invert the hand of the indices, as long as the program which does it also takes care to convert any hand-dependent columns such as anomalous differences, F+/F- etc in the appropriate manner at the same time. The program will also need to convert any phase or phase-coefficient columns, but it will have to do this anyway, even if the hand is not inverted, in those cases where the space group contains screw axes (since then you will get phase shifts on reindexing for certain subsets of reflections). So if the data consist only of I's or F's without anomalous data or phases then inverting the hand will have absolutely no effect (it's called Friedel's Law). I note from the documentation that reindex will invert the hand if the keyword 'LEFT' is supplied, though whether it then treats the anomalous data and phases correctly is anyone's guess! The question is really whether it's likely ever to be _necessary_ to invert the hand; this will depend on the reciprocal space asymmetric unit chosen by the processing program. One could imagine a situation where the a.u. chosen by one processing program was on a different hand from the a.u. required by another. In such a situation you would have no choice but to invert the hand of the indices, though I suspect you would be better off doing it with CAD which will do it reliably, rather than reindex which may not (judging by the comments in the reindex code!). Whether such a situation ever occurs in practice, I don't know, maybe not. Cheers -- Ian On 29 May 2012 09:57, Graeme Winter graeme.win...@gmail.com wrote: Hello Qixu Cai, What you want is a reindexing operator which permutes the axes rather than one which changes the sign of an axis. The easiest way to do this is with pointless: pointless hklin input.mtz hklref reference.mtz hklout output.mtz and let pointless figure out the right operation to use. You may find the following helpful: http://www.ccp4.ac.uk/html/reindexing.html Best wishes, Graeme On 29 May 2012 09:48, Qixu Cai caiq...@gmail.com wrote: Dear all, I have a dataset at P321 space group. And I want to reindex from (h,k,l) to (k,h,l) or (h,k,-l), because I want to merge this dataset to the native dataset. At first, I used the reindex program in CCP4i, and got an error: (either for (k,h,l) or (h,k,-l)) Data line--- reindex HKL h, k, -l Data line--- end $TEXT:Warning: $$ comment $$ WARNING: Reindexing matrix INVERTS hand $$ REINDEX: You are NOT allowed to do this - Changing all signs in reindexing matrix Times: User: 0.0s System: 0.0s Elapsed: 0:00 = Could you please tell me the reason? At last, I converted the mtz file to CNS format, and write a script to exchange the h and k, and converted to mtz file. When I tried to use cad to merge this dataset to the native dataset, if I chose Automatically check and enforce consistent indexing between different files, the index would be changed back to the original index. Why? Thank you very much for your attention. Best wishes, Qixu Cai
Re: [ccp4bb] P321 space group reindex problem
Phil, On 29 May 2012 14:08, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: NO do NOT invert the hand. If you do you will end up with left-handed helices etc Surely not if you take care to also change the signs of the anomalous differences? The alternative indexing systems all need to preserve the right-handed axis system imposed by the data integration program (eg k,h,-l) The ONLY time it is valid to invert the hand is if the indexing/integration program itself inverted the hand due to a bug (this has been know, but not for a long time) Assuming I've got the correct transformations and a.u. in P321 it's only possible to re-index from the alternate setting if the hand is inverted (and the anomalous data any phase columns converted). Cheers -- Ian
Re: [ccp4bb] P321 space group reindex problem
P3 is another possible alternate indexing? is that correct? 2012/5/29 Ian Tickle ianj...@gmail.com Mark, thanks for pointing that out, I see it now: In P321 the only possible alternate indexing is (-h, -k, l): this is a 2-fold || c which is an operator of the hexagonal lattice but is not an equivalent reflection. The standard CCP4 a.u. is h = k, l = 0 or h k, k = 0, so for example (3,2,1) would be in the standard a.u. (3 2 and 2 = 0). In the alternate indexing this would be (-3, -2, 1); however it's impossible to transform this to the a.u. with any non-inverting equivalent. The only possibility is to invert the hand, i.e. to (3, 2, -1) which is again in the a.u.. So the required re-indexing operator to match (3, 2, -1) with (3, 2, 1) is (h, k, -l) which reindex won't allow without the LEFT keyword (and you would be well-advised to avoid doing it with phase columns!). Cheers -- Ian On 29 May 2012 12:55, Mark J van Raaij mjvanra...@cnb.csic.es wrote: In different datasets of P321 crystals, when you index them separately, the hand may be different and you may need to invert it for some. They prohibition in reindex is really a warning, and can be overridden. Mark J van Raaij Laboratorio M-4 Dpto de Estructura de Macromoleculas Centro Nacional de Biotecnologia - CSIC c/Darwin 3 E-28049 Madrid, Spain tel. (+34) 91 585 4616 http://www.cnb.csic.es/~mjvanraaij On 29 May 2012, at 13:52, Ian Tickle wrote: In principle there's no reason why you can't invert the hand of the indices, as long as the program which does it also takes care to convert any hand-dependent columns such as anomalous differences, F+/F- etc in the appropriate manner at the same time. The program will also need to convert any phase or phase-coefficient columns, but it will have to do this anyway, even if the hand is not inverted, in those cases where the space group contains screw axes (since then you will get phase shifts on reindexing for certain subsets of reflections). So if the data consist only of I's or F's without anomalous data or phases then inverting the hand will have absolutely no effect (it's called Friedel's Law). I note from the documentation that reindex will invert the hand if the keyword 'LEFT' is supplied, though whether it then treats the anomalous data and phases correctly is anyone's guess! The question is really whether it's likely ever to be _necessary_ to invert the hand; this will depend on the reciprocal space asymmetric unit chosen by the processing program. One could imagine a situation where the a.u. chosen by one processing program was on a different hand from the a.u. required by another. In such a situation you would have no choice but to invert the hand of the indices, though I suspect you would be better off doing it with CAD which will do it reliably, rather than reindex which may not (judging by the comments in the reindex code!). Whether such a situation ever occurs in practice, I don't know, maybe not. Cheers -- Ian On 29 May 2012 09:57, Graeme Winter graeme.win...@gmail.com wrote: Hello Qixu Cai, What you want is a reindexing operator which permutes the axes rather than one which changes the sign of an axis. The easiest way to do this is with pointless: pointless hklin input.mtz hklref reference.mtz hklout output.mtz and let pointless figure out the right operation to use. You may find the following helpful: http://www.ccp4.ac.uk/html/reindexing.html Best wishes, Graeme On 29 May 2012 09:48, Qixu Cai caiq...@gmail.com wrote: Dear all, I have a dataset at P321 space group. And I want to reindex from (h,k,l) to (k,h,l) or (h,k,-l), because I want to merge this dataset to the native dataset. At first, I used the reindex program in CCP4i, and got an error: (either for (k,h,l) or (h,k,-l)) Data line--- reindex HKL h, k, -l Data line--- end $TEXT:Warning: $$ comment $$ WARNING: Reindexing matrix INVERTS hand $$ REINDEX: You are NOT allowed to do this - Changing all signs in reindexing matrix Times: User: 0.0s System:0.0s Elapsed: 0:00 = Could you please tell me the reason? At last, I converted the mtz file to CNS format, and write a script to exchange the h and k, and converted to mtz file. When I tried to use cad to merge this dataset to the native dataset, if I chose Automatically check and enforce consistent indexing between different files, the index would be changed back to the original index. Why? Thank you very much for your attention. Best wishes, Qixu Cai
Re: [ccp4bb] P321 space group reindex problem
Qixu, yes obviously any sub-group is a possible indexing (all the way down to P1 !). You need to compare your Rpims etc. Cheers -- Ian On 29 May 2012 15:03, Qixu Cai caiq...@gmail.com wrote: P3 is another possible alternate indexing? is that correct? 2012/5/29 Ian Tickle ianj...@gmail.com Mark, thanks for pointing that out, I see it now: In P321 the only possible alternate indexing is (-h, -k, l): this is a 2-fold || c which is an operator of the hexagonal lattice but is not an equivalent reflection. The standard CCP4 a.u. is h = k, l = 0 or h k, k = 0, so for example (3,2,1) would be in the standard a.u. (3 2 and 2 = 0). In the alternate indexing this would be (-3, -2, 1); however it's impossible to transform this to the a.u. with any non-inverting equivalent. The only possibility is to invert the hand, i.e. to (3, 2, -1) which is again in the a.u.. So the required re-indexing operator to match (3, 2, -1) with (3, 2, 1) is (h, k, -l) which reindex won't allow without the LEFT keyword (and you would be well-advised to avoid doing it with phase columns!). Cheers -- Ian On 29 May 2012 12:55, Mark J van Raaij mjvanra...@cnb.csic.es wrote: In different datasets of P321 crystals, when you index them separately, the hand may be different and you may need to invert it for some. They prohibition in reindex is really a warning, and can be overridden. Mark J van Raaij Laboratorio M-4 Dpto de Estructura de Macromoleculas Centro Nacional de Biotecnologia - CSIC c/Darwin 3 E-28049 Madrid, Spain tel. (+34) 91 585 4616 http://www.cnb.csic.es/~mjvanraaij On 29 May 2012, at 13:52, Ian Tickle wrote: In principle there's no reason why you can't invert the hand of the indices, as long as the program which does it also takes care to convert any hand-dependent columns such as anomalous differences, F+/F- etc in the appropriate manner at the same time. The program will also need to convert any phase or phase-coefficient columns, but it will have to do this anyway, even if the hand is not inverted, in those cases where the space group contains screw axes (since then you will get phase shifts on reindexing for certain subsets of reflections). So if the data consist only of I's or F's without anomalous data or phases then inverting the hand will have absolutely no effect (it's called Friedel's Law). I note from the documentation that reindex will invert the hand if the keyword 'LEFT' is supplied, though whether it then treats the anomalous data and phases correctly is anyone's guess! The question is really whether it's likely ever to be _necessary_ to invert the hand; this will depend on the reciprocal space asymmetric unit chosen by the processing program. One could imagine a situation where the a.u. chosen by one processing program was on a different hand from the a.u. required by another. In such a situation you would have no choice but to invert the hand of the indices, though I suspect you would be better off doing it with CAD which will do it reliably, rather than reindex which may not (judging by the comments in the reindex code!). Whether such a situation ever occurs in practice, I don't know, maybe not. Cheers -- Ian On 29 May 2012 09:57, Graeme Winter graeme.win...@gmail.com wrote: Hello Qixu Cai, What you want is a reindexing operator which permutes the axes rather than one which changes the sign of an axis. The easiest way to do this is with pointless: pointless hklin input.mtz hklref reference.mtz hklout output.mtz and let pointless figure out the right operation to use. You may find the following helpful: http://www.ccp4.ac.uk/html/reindexing.html Best wishes, Graeme On 29 May 2012 09:48, Qixu Cai caiq...@gmail.com wrote: Dear all, I have a dataset at P321 space group. And I want to reindex from (h,k,l) to (k,h,l) or (h,k,-l), because I want to merge this dataset to the native dataset. At first, I used the reindex program in CCP4i, and got an error: (either for (k,h,l) or (h,k,-l)) Data line--- reindex HKL h, k, -l Data line--- end $TEXT:Warning: $$ comment $$ WARNING: Reindexing matrix INVERTS hand $$ REINDEX: You are NOT allowed to do this - Changing all signs in reindexing matrix Times: User: 0.0s System: 0.0s Elapsed: 0:00 = Could you please tell me the reason? At last, I converted the mtz file to CNS format, and write a script to exchange the h and k, and converted to mtz file. When I tried to use cad to merge this dataset to the native dataset, if I chose Automatically check and enforce consistent indexing between different files, the index would be changed back to the original index. Why? Thank you very much for your attention.
Re: [ccp4bb] P321 space group reindex problem
On 29 May 2012, at 15:02, Ian Tickle wrote: Phil, On 29 May 2012 14:08, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: NO do NOT invert the hand. If you do you will end up with left-handed helices etc Surely not if you take care to also change the signs of the anomalous differences? I suppose that's true (I think) but it's no harder to do it properly (ie preserving the hand The alternative indexing systems all need to preserve the right-handed axis system imposed by the data integration program (eg k,h,-l) The ONLY time it is valid to invert the hand is if the indexing/integration program itself inverted the hand due to a bug (this has been know, but not for a long time) Assuming I've got the correct transformations and a.u. in P321 it's only possible to re-index from the alternate setting if the hand is inverted (and the anomalous data any phase columns converted). No the hand-preserving transformation in 321 is (k,h,-l) Phil Cheers -- Ian
Re: [ccp4bb] P321 space group reindex problem
Which programs require that the data be the 'standard' a.u.? None of mine require this. George On 05/29/2012 03:44 PM, Ian Tickle wrote: Mark, thanks for pointing that out, I see it now: In P321 the only possible alternate indexing is (-h, -k, l): this is a 2-fold || c which is an operator of the hexagonal lattice but is not an equivalent reflection. The standard CCP4 a.u. is h = k, l= 0 or h k, k= 0, so for example (3,2,1) would be in the standard a.u. (3 2 and 2= 0). In the alternate indexing this would be (-3, -2, 1); however it's impossible to transform this to the a.u. with any non-inverting equivalent. The only possibility is to invert the hand, i.e. to (3, 2, -1) which is again in the a.u.. So the required re-indexing operator to match (3, 2, -1) with (3, 2, 1) is (h, k, -l) which reindex won't allow without the LEFT keyword (and you would be well-advised to avoid doing it with phase columns!). Cheers -- Ian -- Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582
Re: [ccp4bb] P321 space group reindex problem
Phil, On 29 May 2012 15:09, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: No the hand-preserving transformation in 321 is (k,h,-l) But that's an equivalent of the space group so it won't transform from the alternate setting (-h, -k, l). It will just give you a _different_ a.u. of the _same_ setting. We need the _same_ a.u. of the _different_ setting! Cheers -- Ian
Re: [ccp4bb] P321 space group reindex problem
Although there is no need for a standard reciprocal asu, it is convenient to have all your datasets in the same convention when it comes to comparing and combining different isomorphous datasets (ie to do it once rather than every time you compare them). It doesn't matter what the standard is as long as it is consistent Reading Ian's Email more carefully, it is true that eg in 321 the reindexing k,h,-l may take it out of the standard asu, and need an inversion operator to put it back. In that case, Pointless (and Reindex) do reduce the hkl to the asu and swap anomalous columns, and pointless will also invert phase columns etc No the hand-preserving transformation in 321 is (k,h,-l) But that's an equivalent of the space group so it won't transform from the alternate setting (-h, -k, l). It will just give you a _different_ a.u. of the _same_ setting. We need the _same_ a.u. of the _different_ setting! Apologies, you are right, for 321 the reindexing operator is (-h,-k,l). But Pointless will do it correctly (I believe!) Phil On 29 May 2012, at 14:29, George Sheldrick wrote: Which programs require that the data be the 'standard' a.u.? None of mine require this. George On 05/29/2012 03:44 PM, Ian Tickle wrote: Mark, thanks for pointing that out, I see it now: In P321 the only possible alternate indexing is (-h, -k, l): this is a 2-fold || c which is an operator of the hexagonal lattice but is not an equivalent reflection. The standard CCP4 a.u. is h = k, l= 0 or h k, k= 0, so for example (3,2,1) would be in the standard a.u. (3 2 and 2= 0). In the alternate indexing this would be (-3, -2, 1); however it's impossible to transform this to the a.u. with any non-inverting equivalent. The only possibility is to invert the hand, i.e. to (3, 2, -1) which is again in the a.u.. So the required re-indexing operator to match (3, 2, -1) with (3, 2, 1) is (h, k, -l) which reindex won't allow without the LEFT keyword (and you would be well-advised to avoid doing it with phase columns!). Cheers -- Ian -- Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582
Re: [ccp4bb] P321 space group reindex problem
George The CCP4 programs (I can't speak for others) involved with isomorphous replacement, i.e. scaling, FFT for difference Pattersons Fouriers, and heavy-atom refinement (e.g. MLPHARE), mostly require that the native data and that of all the derivatives be not only in the same a.u. but sorted identically, so the preceding programs such as CAD go to a lot of trouble to ensure this. Cheers -- Ian On 29 May 2012 14:29, George Sheldrick gshe...@shelx.uni-ac.gwdg.de wrote: Which programs require that the data be the 'standard' a.u.? None of mine require this. George On 05/29/2012 03:44 PM, Ian Tickle wrote: Mark, thanks for pointing that out, I see it now: In P321 the only possible alternate indexing is (-h, -k, l): this is a 2-fold || c which is an operator of the hexagonal lattice but is not an equivalent reflection. The standard CCP4 a.u. is h = k, l= 0 or h k, k= 0, so for example (3,2,1) would be in the standard a.u. (3 2 and 2= 0). In the alternate indexing this would be (-3, -2, 1); however it's impossible to transform this to the a.u. with any non-inverting equivalent. The only possibility is to invert the hand, i.e. to (3, 2, -1) which is again in the a.u.. So the required re-indexing operator to match (3, 2, -1) with (3, 2, 1) is (h, k, -l) which reindex won't allow without the LEFT keyword (and you would be well-advised to avoid doing it with phase columns!). Cheers -- Ian -- Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582
Re: [ccp4bb] P321 space group reindex problem
Dear all, thank you for your help. I think I must describe my case in detail. I collected a native dataset and two heavy atom derivant datasets （in fact, i don not know whether these two kind of heavy atom have soked into the crystal, i just collect the data to check it）. i processed all of three datasets with automar, and merged them by CAD. I used scaleit to get the Rfactor between datasets and got a strange result. the R factor between derivant1 and native is 26% and the R factor between derivant2 and native is 59%! so I think it may be the problem of index （space group is P321）. so i exchange the h and k of derivant2 by the some awk script and merged to native data by CAD. After scaleit analysis, I got the R factor 29% between derivant2 and native. Here is my questions, 1, at my case, is that right to invert the hand? is that the special problem of the P3 or p321 space group? 2, I have carryed out some suggestion of yours, such as use pointless （use native data as reference for derivant2 reindex）, or reindex the derivant2 dataset by （k, h, -l）, and I always got the high R factor 59% between derivant2 and native. Any suggestion? thanks a lot! Qixu Cai 在 2012-5-29，下午10:36，Laurent Maveyraud laurent.maveyr...@ipbs.fr 写道： Hi... and apologies ! I was a little quick in my answer... in P321, h k l and -h -k l are valid indexing schemes... It is in P3 that you can have h k l and k h -l as Ian and Phil agreed on the BB ! sorry, laurent Hi, you might have several possible spacegroups possible when processing your data (at the indexation step). These will be based on the metrics of your cell (vector length and angles). If you happen to have something like a = b, and alpha=beta90° and gamma=120°, then it is likely that your crystal is trigonal or hexagonal. You will have to wait until the scaling step (or pointless after integration) in order to decide which spacegroup is the right one, based on the symmetry operations in your dataset and on systematic absences. There you have to choose between P3, P31, P32, P312, P321 in trigonal. When comparing two datasets from trigonal crystals, even for identical crystals and hence identical spacegroups, you have different ways to index your dataset... In P321, one dataset might be indexed one way (eg. h k l), the other might be index the other way (k h -l). When you compared this two dataset, they will appear to be different, because both indexing schemes, although valid, are not equivalent. Take one reflection; e.g. 3 2 1 from your crystal A. The very same reflection will be indexed 2 3 -1 for your crystal B, and the one indexed 3 2 1 for crytal B will not be equivalent to the 3 2 1 reflection from crystal A. If you try to merge your two datasets, you will have huge Rmerge, because you are trying to average non equivalent reflections. You will have to ensure that the same indexing scheme is used for both datasets, eg reindex B using the reindex k h -l command in reindex, before being able to merge A and B. hope this helps... please feel free to as if I am not clear... best regards laurent Le 29/05/2012 16:03, Qixu Cai a écrit : P3 is another possible alternate indexing? is that correct? 2012/5/29 Ian Tickle ianj...@gmail.com mailto:ianj...@gmail.com Mark, thanks for pointing that out, I see it now: In P321 the only possible alternate indexing is (-h, -k, l): this is a 2-fold || c which is an operator of the hexagonal lattice but is not an equivalent reflection. The standard CCP4 a.u. is h = k, l = 0 or h k, k = 0, so for example (3,2,1) would be in the standard a.u. (3 2 and 2 = 0). In the alternate indexing this would be (-3, -2, 1); however it's impossible to transform this to the a.u. with any non-inverting equivalent. The only possibility is to invert the hand, i.e. to (3, 2, -1) which is again in the a.u.. So the required re-indexing operator to match (3, 2, -1) with (3, 2, 1) is (h, k, -l) which reindex won't allow without the LEFT keyword (and you would be well-advised to avoid doing it with phase columns!). Cheers -- Ian On 29 May 2012 12:55, Mark J van Raaij mjvanra...@cnb.csic.es mailto:mjvanra...@cnb.csic.es wrote: In different datasets of P321 crystals, when you index them separately, the hand may be different and you may need to invert it for some. They prohibition in reindex is really a warning, and can be overridden. Mark J van Raaij Laboratorio M-4 Dpto de Estructura de Macromoleculas Centro Nacional de Biotecnologia - CSIC c/Darwin 3 E-28049 Madrid, Spain tel. (+34) 91 585 4616 http://www.cnb.csic.es/~mjvanraaij http://www.cnb.csic.es/%7Emjvanraaij On 29 May 2012, at 13:52, Ian Tickle wrote: In principle there's no reason why you can't invert the hand of
Re: [ccp4bb] P321 space group reindex problem
How do you know the point group is 321? What does Pointless tell you if you put in the unmerged data? Despite some of the things said earlier (by me!), the possible indexing schemes in 321 are h,k,l and -h,-k,l If that doesn't work, it suggests that the point group is a lower symmetry eg P3 Phil On 29 May 2012, at 16:29, Qixu Cai wrote: Dear all, thank you for your help. I think I must describe my case in detail. I collected a native dataset and two heavy atom derivant datasets （in fact, i don not know whether these two kind of heavy atom have soked into the crystal, i just collect the data to check it）. i processed all of three datasets with automar, and merged them by CAD. I used scaleit to get the Rfactor between datasets and got a strange result. the R factor between derivant1 and native is 26% and the R factor between derivant2 and native is 59%! so I think it may be the problem of index （space group is P321）. so i exchange the h and k of derivant2 by the some awk script and merged to native data by CAD. After scaleit analysis, I got the R factor 29% between derivant2 and native. Here is my questions, 1, at my case, is that right to invert the hand? is that the special problem of the P3 or p321 space group? 2, I have carryed out some suggestion of yours, such as use pointless （use native data as reference for derivant2 reindex）, or reindex the derivant2 dataset by （k, h, -l）, and I always got the high R factor 59% between derivant2 and native. Any suggestion? thanks a lot! Qixu Cai 在 2012-5-29，下午10:36，Laurent Maveyraud laurent.maveyr...@ipbs.fr 写道： Hi... and apologies ! I was a little quick in my answer... in P321, h k l and -h -k l are valid indexing schemes... It is in P3 that you can have h k l and k h -l as Ian and Phil agreed on the BB ! sorry, laurent Hi, you might have several possible spacegroups possible when processing your data (at the indexation step). These will be based on the metrics of your cell (vector length and angles). If you happen to have something like a = b, and alpha=beta90° and gamma=120°, then it is likely that your crystal is trigonal or hexagonal. You will have to wait until the scaling step (or pointless after integration) in order to decide which spacegroup is the right one, based on the symmetry operations in your dataset and on systematic absences. There you have to choose between P3, P31, P32, P312, P321 in trigonal. When comparing two datasets from trigonal crystals, even for identical crystals and hence identical spacegroups, you have different ways to index your dataset... In P321, one dataset might be indexed one way (eg. h k l), the other might be index the other way (k h -l). When you compared this two dataset, they will appear to be different, because both indexing schemes, although valid, are not equivalent. Take one reflection; e.g. 3 2 1 from your crystal A. The very same reflection will be indexed 2 3 -1 for your crystal B, and the one indexed 3 2 1 for crytal B will not be equivalent to the 3 2 1 reflection from crystal A. If you try to merge your two datasets, you will have huge Rmerge, because you are trying to average non equivalent reflections. You will have to ensure that the same indexing scheme is used for both datasets, eg reindex B using the reindex k h -l command in reindex, before being able to merge A and B. hope this helps... please feel free to as if I am not clear... best regards laurent Le 29/05/2012 16:03, Qixu Cai a écrit : P3 is another possible alternate indexing? is that correct? 2012/5/29 Ian Tickle ianj...@gmail.com mailto:ianj...@gmail.com Mark, thanks for pointing that out, I see it now: In P321 the only possible alternate indexing is (-h, -k, l): this is a 2-fold || c which is an operator of the hexagonal lattice but is not an equivalent reflection. The standard CCP4 a.u. is h = k, l = 0 or h k, k = 0, so for example (3,2,1) would be in the standard a.u. (3 2 and 2 = 0). In the alternate indexing this would be (-3, -2, 1); however it's impossible to transform this to the a.u. with any non-inverting equivalent. The only possibility is to invert the hand, i.e. to (3, 2, -1) which is again in the a.u.. So the required re-indexing operator to match (3, 2, -1) with (3, 2, 1) is (h, k, -l) which reindex won't allow without the LEFT keyword (and you would be well-advised to avoid doing it with phase columns!). Cheers -- Ian On 29 May 2012 12:55, Mark J van Raaij mjvanra...@cnb.csic.es mailto:mjvanra...@cnb.csic.es wrote: In different datasets of P321 crystals, when you index them separately, the hand may be different and you may need to invert it for some. They prohibition in reindex is really a warning, and can be overridden. Mark J van Raaij Laboratorio M-4 Dpto de Estructura de Macromoleculas
Re: [ccp4bb] P321 space group reindex problem
Hi Qixu Whether it's valid to simply swap h and k depends on whether you have anomalous data (I assume you don't have any phases at this stage). If not there's no issue with inverting the hand, but if you do then you must either remove the anomalous data to avoid confusing yourself and others later on, or change the sign of the anomalous differences (or swap F-/F+ and/or I-/I+ as appropriate). You swapped h and k i.e. (h, k, l) to (k, h, l): taken with the equivalent reflection (k, h, -l) this gives (h, k, -l) which is exactly the index transformation that I derived (see my previous email). You could have done the same thing with reindex using h,k,-l and the LEFT keyword (in fact I would stick to well-tried programs!). So with my proviso about anomalous data above, what you have done is completely correct and the R factor of 29% that you got for derivative 2 (assuming I've understood you correctly) supports this. I can't explain why pointless appears not to have worked, Phil is the person to ask about that. Cheers -- Ian On 29 May 2012 16:29, Qixu Cai caiq...@gmail.com wrote: Dear all, thank you for your help. I think I must describe my case in detail. I collected a native dataset and two heavy atom derivant datasets （in fact, i don not know whether these two kind of heavy atom have soked into the crystal, i just collect the data to check it）. i processed all of three datasets with automar, and merged them by CAD. I used scaleit to get the Rfactor between datasets and got a strange result. the R factor between derivant1 and native is 26% and the R factor between derivant2 and native is 59%! so I think it may be the problem of index （space group is P321）. so i exchange the h and k of derivant2 by the some awk script and merged to native data by CAD. After scaleit analysis, I got the R factor 29% between derivant2 and native. Here is my questions, 1, at my case, is that right to invert the hand? is that the special problem of the P3 or p321 space group? 2, I have carryed out some suggestion of yours, such as use pointless （use native data as reference for derivant2 reindex）, or reindex the derivant2 dataset by （k, h, -l）, and I always got the high R factor 59% between derivant2 and native. Any suggestion? thanks a lot! Qixu Cai 在 2012-5-29，下午10:36，Laurent Maveyraud laurent.maveyr...@ipbs.fr 写道： Hi... and apologies ! I was a little quick in my answer... in P321, h k l and -h -k l are valid indexing schemes... It is in P3 that you can have h k l and k h -l as Ian and Phil agreed on the BB ! sorry, laurent Hi, you might have several possible spacegroups possible when processing your data (at the indexation step). These will be based on the metrics of your cell (vector length and angles). If you happen to have something like a = b, and alpha=beta90° and gamma=120°, then it is likely that your crystal is trigonal or hexagonal. You will have to wait until the scaling step (or pointless after integration) in order to decide which spacegroup is the right one, based on the symmetry operations in your dataset and on systematic absences. There you have to choose between P3, P31, P32, P312, P321 in trigonal. When comparing two datasets from trigonal crystals, even for identical crystals and hence identical spacegroups, you have different ways to index your dataset... In P321, one dataset might be indexed one way (eg. h k l), the other might be index the other way (k h -l). When you compared this two dataset, they will appear to be different, because both indexing schemes, although valid, are not equivalent. Take one reflection; e.g. 3 2 1 from your crystal A. The very same reflection will be indexed 2 3 -1 for your crystal B, and the one indexed 3 2 1 for crytal B will not be equivalent to the 3 2 1 reflection from crystal A. If you try to merge your two datasets, you will have huge Rmerge, because you are trying to average non equivalent reflections. You will have to ensure that the same indexing scheme is used for both datasets, eg reindex B using the reindex k h -l command in reindex, before being able to merge A and B. hope this helps... please feel free to as if I am not clear... best regards laurent Le 29/05/2012 16:03, Qixu Cai a écrit : P3 is another possible alternate indexing? is that correct? 2012/5/29 Ian Tickle ianj...@gmail.com mailto:ianj...@gmail.com Mark, thanks for pointing that out, I see it now: In P321 the only possible alternate indexing is (-h, -k, l): this is a 2-fold || c which is an operator of the hexagonal lattice but is not an equivalent reflection. The standard CCP4 a.u. is h = k, l = 0 or h k, k = 0, so for example (3,2,1) would be in the standard a.u. (3 2 and 2 = 0). In the alternate indexing this would be (-3, -2, 1); however it's impossible to transform this to the a.u. with any non-inverting equivalent. The
Re: [ccp4bb] P321 space group reindex problem
At first, I processed the data at P3 space group. But after phenix.xtriage analysis, the Xtriage told me the space group must be P321, so I used P321 to process my data, and got an acceptable Rmerge. Qixu Cai 2012/5/29 Phil Evans p...@mrc-lmb.cam.ac.uk How do you know the point group is 321? What does Pointless tell you if you put in the unmerged data? Despite some of the things said earlier (by me!), the possible indexing schemes in 321 are h,k,l and -h,-k,l If that doesn't work, it suggests that the point group is a lower symmetry eg P3 Phil On 29 May 2012, at 16:29, Qixu Cai wrote: Dear all, thank you for your help. I think I must describe my case in detail. I collected a native dataset and two heavy atom derivant datasets （in fact, i don not know whether these two kind of heavy atom have soked into the crystal, i just collect the data to check it）. i processed all of three datasets with automar, and merged them by CAD. I used scaleit to get the Rfactor between datasets and got a strange result. the R factor between derivant1 and native is 26% and the R factor between derivant2 and native is 59%! so I think it may be the problem of index （space group is P321）. so i exchange the h and k of derivant2 by the some awk script and merged to native data by CAD. After scaleit analysis, I got the R factor 29% between derivant2 and native. Here is my questions, 1, at my case, is that right to invert the hand? is that the special problem of the P3 or p321 space group? 2, I have carryed out some suggestion of yours, such as use pointless （use native data as reference for derivant2 reindex）, or reindex the derivant2 dataset by （k, h, -l）, and I always got the high R factor 59% between derivant2 and native. Any suggestion? thanks a lot! Qixu Cai 在 2012-5-29，下午10:36，Laurent Maveyraud laurent.maveyr...@ipbs.fr 写道： Hi... and apologies ! I was a little quick in my answer... in P321, h k l and -h -k l are valid indexing schemes... It is in P3 that you can have h k l and k h -l as Ian and Phil agreed on the BB ! sorry, laurent Hi, you might have several possible spacegroups possible when processing your data (at the indexation step). These will be based on the metrics of your cell (vector length and angles). If you happen to have something like a = b, and alpha=beta90° and gamma=120°, then it is likely that your crystal is trigonal or hexagonal. You will have to wait until the scaling step (or pointless after integration) in order to decide which spacegroup is the right one, based on the symmetry operations in your dataset and on systematic absences. There you have to choose between P3, P31, P32, P312, P321 in trigonal. When comparing two datasets from trigonal crystals, even for identical crystals and hence identical spacegroups, you have different ways to index your dataset... In P321, one dataset might be indexed one way (eg. h k l), the other might be index the other way (k h -l). When you compared this two dataset, they will appear to be different, because both indexing schemes, although valid, are not equivalent. Take one reflection; e.g. 3 2 1 from your crystal A. The very same reflection will be indexed 2 3 -1 for your crystal B, and the one indexed 3 2 1 for crytal B will not be equivalent to the 3 2 1 reflection from crystal A. If you try to merge your two datasets, you will have huge Rmerge, because you are trying to average non equivalent reflections. You will have to ensure that the same indexing scheme is used for both datasets, eg reindex B using the reindex k h -l command in reindex, before being able to merge A and B. hope this helps... please feel free to as if I am not clear... best regards laurent Le 29/05/2012 16:03, Qixu Cai a écrit : P3 is another possible alternate indexing? is that correct? 2012/5/29 Ian Tickle ianj...@gmail.com mailto:ianj...@gmail.com Mark, thanks for pointing that out, I see it now: In P321 the only possible alternate indexing is (-h, -k, l): this is a 2-fold || c which is an operator of the hexagonal lattice but is not an equivalent reflection. The standard CCP4 a.u. is h = k, l = 0 or h k, k = 0, so for example (3,2,1) would be in the standard a.u. (3 2 and 2 = 0). In the alternate indexing this would be (-3, -2, 1); however it's impossible to transform this to the a.u. with any non-inverting equivalent. The only possibility is to invert the hand, i.e. to (3, 2, -1) which is again in the a.u.. So the required re-indexing operator to match (3, 2, -1) with (3, 2, 1) is (h, k, -l) which reindex won't allow without the LEFT keyword (and you would be well-advised to avoid doing it with phase columns!). Cheers -- Ian On 29 May 2012 12:55, Mark J van Raaij mjvanra...@cnb.csic.es mailto:mjvanra...@cnb.csic.es wrote: In different
