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> > 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.fr<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> <mailto: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**> >> >>> <mailto: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> >> >> <http://www.cnb.csic.es/%**7Emjvanraaij<http://www.cnb.csic.es/%7Emjvanraaij> >> > >> >>> >> <http://www.cnb.csic.es/%**7Emjvanraaij<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.winter@gmail.**com <graeme.win...@gmail.com>> >> >>> <mailto:graeme.winter@gmail.**com <graeme.win...@gmail.com> >> >> <mailto:graeme.winter@gmail.**com <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<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> >> >>> <mailto: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 >> >> ------------------------------**---------------------------- >> >> >> >> >> > -- > ------------------------------**---------------------------- > 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 > ------------------------------**---------------------------- > >
