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 <[log in to unmask] <mailto:[log in to unmask]>>
>
> 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
> <[log in to unmask] <mailto:[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]> <mailto:[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]>
> >>> <mailto:[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>
> >>> <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]>
> >>> <mailto:[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]>
> >>> <mailto:[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
> >> ----------------------------------------------------------
> >>
>
>
--
----------------------------------------------------------
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
----------------------------------------------------------
|