 |
 |
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 <[log in to unmask]> 写道： > 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 <[log in to unmask] <mailto:[log in to unmask]>> >> >> 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 <[log in to unmask] >> <mailto:[log in to unmask]>> 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 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 <[log in to unmask] >> <mailto:[log in to unmask]>> 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 <[log in to unmask] >> <mailto:[log in to unmask]>> 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 >> >> > > -- > ---------------------------------------------------------- > Laurent Maveyraud laurent.maveyraud AT ipbs DOT fr > Université Paul Sabatier / CNRS / I.P.B.S. UMR 5089 > PICT -- Plateforme Intégrée de Criblage de Toulouse > Département Biologie Structurale et Biophysique > BP 64182 - 205 rte de Narbonne - 31077 TOULOUSE FRANCE > Tél: +33 (0)561 175 435 Fax : +33 (0)561 175 994 > ---------------------------------------------------------- >