JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for CCP4BB Archives


CCP4BB Archives

CCP4BB Archives


CCP4BB@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CCP4BB Home

CCP4BB Home

CCP4BB  May 2012

CCP4BB May 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: P321 space group reindex problem

From:

Qixu Cai <[log in to unmask]>

Reply-To:

Qixu Cai <[log in to unmask]>

Date:

Tue, 29 May 2012 23:29:43 +0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (220 lines)

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]> 写道:

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

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager