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 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 <graeme.win...@gmail.com > >>> <mailto: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 > >>> <mailto: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 > >>> > >>> > >> > >> -- > >> ---------------------------------------------------------- > >> 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 > >> ---------------------------------------------------------- > >> >
