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