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.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>
>>>>
>>>>
>>>>
>>>> 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>>> 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>>> 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
>> ----------------------------------------------------------
>>
