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