Re: [ccp4bb] XDSAPP - A new GUI for data processing using XDS

[Daniel Ericsson]

Very neat.

Is there some way to set parameters not listed under 'Settings'? Data from
the Australian Synchrotron uses ROTATION_AXIS=-1.0 0.0 0.0 but I haven't
figured out how to change this. Editing the generated XDS.INP between runs
doesn't seem to do it.

Cheers,
/Daniel

-- 
Daniel Ericsson
Postdoctoral Research Fellow

Kobe group
School of Chemistry and Molecular Bioscience
University of Queensland
d.erics...@uq.edu.au
+61 44 99 23 036


On Tue, May 29, 2012 at 10:39 PM, Müller, Uwe wrote:

>  Dear CCP4BB users,
>
> we would hereby like to introduce XDSAPP, a GUI for the easy and
> convenient processing of diffraction data sets using XDS (see also
> Krug et al. (2012). J. Appl. Cryst. 45, 568-572).
>
> XDSAPP automates the data processing, generates plots of various
> data set statistics and produces intensity files suitable for further
> analysis using CCP4, SHELX and CNS.
>
> XDSAPP has the following features:
>   - detector support for Rayonics MX-225, MARCCD-165 mm, PILATUS 6M  and
> ADSC Quantum Q315r
>   -  Successfully tested on various Linux platforms
>   - Full XDS-multiprocessor support
>   -  Space group determination using pointless
>   -  Twinning and pseudo-translation analysis using phenix.xtriage and
> sfcheck  (CCP4 and PHENIX programs must be installed separately)
>   -  Life graphics during Integration
>   -  Graphical output of statistics of CORRECT and XDSSTAT (XDSSTAT must
> be installed separately)
>   -   All XDS output files (.pck, .cbf, .LP) available for viewing within
> the GUI
>   -   Automatic multi-crystal processing
>   -  Output files in mtz, hkl and cv format
>
> XDSAPP is freely available for academics.
>
> More information on XDSAPP including download instructions can be found
> at:
> http://www.helmholtz-berlin.de/bessy-mx
>
>
>  Uwe Mueller, Manfred S. Weiss and Michael Krug
>
>
>  Dr. Uwe Mueller
> Soft Matter and Functional Materials
> Macromolecular Crystallography (BESSY-MX) | Group leader
> Elektronenspeicherring BESSY II
> Albert-Einstein-Str. 15, D-12489 Berlin, Germany
>
> Fon: +49 30 8062 14974
> Fax: +49 30 8062 14975
> url: www.helmholtz-berlin.de/bessy-mx
> email:u...@helmholtz-berlin.de*
> *
>
>
> --
>
> Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
>
> Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher
> Forschungszentren e.V.
>
> Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv.
> Vorsitzende Dr. Beatrix Vierkorn-Rudolph
> Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking
>
> Sitz Berlin, AG Charlottenburg, 89 HRB 5583
>
> Postadresse:
> Hahn-Meitner-Platz 1
> D-14109 Berlin
>
> http://www.helmholtz-berlin.de
>

Re: [ccp4bb] P321 space group reindex problem

[Laurent Maveyraud]

Hi,

Le 30/05/2012 08:29, Qixu Cai a écrit :

Thank you for your remind of the twin problem.

It is always a pleasure to be helpful ;-)
By the way, you stated the spacegoup is P321... did you check systematic 
absences  ? could it be P3121 / P3221 ?




I checked all of the datasets by Xtriage, and found that the native is
not twinned, but the derivant1 and derivant2 are both twinned.

So is the Rfactor between derivants and native useful for the judgement
of the success of the heavy atom soaking?


Well, the unhelpful answer will be : it depends
what is your twin fraction ? how does the scaling derivative/native 
perfom (in details... not only global Rfactors)


Did you try to calculate Patterson maps (isomorphous and anomalous) ?

I would try to find a good MIR tutorial (CCP4 website might be a good 
place to look at, but have a look at phenix website...), and try to 
adapt it to your specific case...


good luck !

laurent


Thanks.

Best wishes,

Qixu Cai




2012/5/30 Laurent Maveyraud 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 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
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
ba

Re: [ccp4bb] P321 space group reindex problem

[Qixu Cai]

 Thank you for your remind of the twin problem.

I checked all of the datasets by Xtriage, and found that the native is not
twinned, but the derivant1 and derivant2 are both twinned.

So is the Rfactor between derivants and native useful for the judgement of
the success of the heavy atom soaking?

Thanks.

Best wishes,

Qixu Cai




2012/5/30 Laurent Maveyraud 

> 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 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
>>> >
>> 写道：
>>
>> >
>> >> 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 you

Re: [ccp4bb] P321 space group reindex problem

[Qixu Cai]

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
120Rfactor to native: 26%
derivative2 cell constant: 181.527 181.527 109.32 90 90
120Rfactor 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 

> 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 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
>>> >
>> 写道：
>>
>> >
>> >> 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 app

Re: [ccp4bb] MAD data process problem

[Laurent Maveyraud]

Hi,

you are right, the peak dataset corresponds to the highest f'' value. 
However, this does not mean that f'' is null for the other 
wavelengthes... you still have significant anomalous signal at the edge 
and for the high energy remote wavelength... this will help your 
phasing, so use it !


As Tim mentionned it : process all wavelength with anomalous switched on !

laurent

Le 30/05/2012 07:59, Qixu Cai a écrit :

Thank you very much for your reply.

In my own understanding,

We collect the peak dataset, because of the large F'', and we can get
strong anomalous signal.

We collect the edge dataset, because of the large F', and combined with
the remote dataset, we can use the method just like SIR to get some
information about the phase.

so I think for peak dataset, anomalous processing is necessary, and for
edge and remote dataset, anomalous processing is not necessary.

Is my understanding correct?

Thank you very much for your help.

Best wish,

Qixu Cai


2012/5/29 Tim Gruene mailto:t...@shelx.uni-ac.gwdg.de>>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Qixu Cai,

MAD phasing is based on the comparison of Bijvoet-pairs, i.e. I(hkl)
with I(-h-k-l), both within one data set and between data sets.
Therefore you might get better results if your integration program does
not assume Friedel-pairs to have identical intensities, even though
the difference is probably only marginal (integration programs do not
merge data).
So it is safest click on 'anomalous' for all data sets involved .

Tim

On 05/29/12 11:11, Qixu Cai wrote:
 > Dear all,
 >
 > Sorry for the question from MAD beginner.
 >
 > When we process the MAD datasets, including the peak-data,
 > edge-data and remote-data, which datasets need to be process with
 > anomalous?
 >
 > I know peak-data obviously need data processing with anomalous, but
 > what about edge-data and remote-data when we want to use MAD
 > method?
 >
 > Thank you very much!
 >
 > Best wishes,
 >
 > Qixu Cai
 >

- --
- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen

GPG Key ID = A46BEE1A

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPxJfaUxlJ7aRr7hoRAm3EAKCKkyvT8z0wg6MFjflkHkiq8RR5GQCgyvF3
lOIOLypSzCcN3N6OR/3NcC8=
=m6ax
-END PGP SIGNATURE-




--
--
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 BiologieStructurale   et   Biophysique
BP 64182  -  205 rte de Narbonne  -  31077 TOULOUSE FRANCE
Tél: +33 (0)561 175 435   Fax : +33 (0)561 175 994
--

Re: [ccp4bb] MAD data process problem

[Qixu Cai]

Thank you very much for your reply.

In my own understanding,

We collect the peak dataset, because of the large F'', and we can get
strong anomalous signal.

We collect the edge dataset, because of the large F', and combined with the
remote dataset, we can use the method just like SIR to get some information
about the phase.

so I think for peak dataset, anomalous processing is necessary, and for
edge and remote dataset, anomalous processing is not necessary.

Is my understanding correct?

Thank you very much for your help.

Best wish,

Qixu Cai


2012/5/29 Tim Gruene 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear Qixu Cai,
>
> MAD phasing is based on the comparison of Bijvoet-pairs, i.e. I(hkl)
> with I(-h-k-l), both within one data set and between data sets.
> Therefore you might get better results if your integration program does
> not assume Friedel-pairs to have identical intensities, even though
> the difference is probably only marginal (integration programs do not
> merge data).
> So it is safest click on 'anomalous' for all data sets involved .
>
> Tim
>
> On 05/29/12 11:11, Qixu Cai wrote:
> > Dear all,
> >
> > Sorry for the question from MAD beginner.
> >
> > When we process the MAD datasets, including the peak-data,
> > edge-data and remote-data, which datasets need to be process with
> > anomalous?
> >
> > I know peak-data obviously need data processing with anomalous, but
> > what about edge-data and remote-data when we want to use MAD
> > method?
> >
> > Thank you very much!
> >
> > Best wishes,
> >
> > Qixu Cai
> >
>
> - --
> - --
> Dr Tim Gruene
> Institut fuer anorganische Chemie
> Tammannstr. 4
> D-37077 Goettingen
>
> GPG Key ID = A46BEE1A
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFPxJfaUxlJ7aRr7hoRAm3EAKCKkyvT8z0wg6MFjflkHkiq8RR5GQCgyvF3
> lOIOLypSzCcN3N6OR/3NcC8=
> =m6ax
> -END PGP SIGNATURE-
>

Re: [ccp4bb] P321 space group reindex problem

[Laurent Maveyraud]

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

Re: [ccp4bb] P321 space group reindex problem

[Qixu Cai]

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 

> 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  写道：
> >
> >> 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 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 w

Re: [ccp4bb] find water in coot

[Dayana Nisbar]

Thank you all for your input.


On Wednesday, May 30, 2012, Paul Emsley  wrote:
> On 29/05/12 19:49, Dayana Nisbar wrote:
>>
>> I need help with finding water in my protein structure using Coot.
>>
>> I tried to find water with peaks above 1.6 sigma for both the 2Fo-Fc and
mFo-DFc maps.
>>
>> The result were 253 water molecules found for 2Fo-Fc map and 563 water
molecules found for mFo-DFc map.
>>
>> My question is
>>
>> 1) Why  is it the number of water molecules are different?
>
> Because the map you are searching are different.  The peaks have
different positions, shape and distance to protein atoms.
>
>> 2) Which map should we use to correctly place the water molecules?
>
> I prefer the 2Fo-Fc style map.  You could create a weighted average of
these maps if you wish.
>
>> 3) What is the sigma cut-off for finding water?
>
> How "deep" do you want to delve into you map?  There is a lot of shape at
0.1 rmsd - do you want to model that?  (Most people do not).  Most people
are happy to model density features around 1 rmsd for 2FoFc-style map and
around 3 rmsd for the difference map.  (Not to say, of course, that 1 rmsd
has much meaning for 2FoFc-style map, but as a rule of thumb, it is not bad
at about 1.8-2.2A and solvent content 55+/-7% in my experience).
>
>> 4) How can I validate these water molecules?
>>
>
> Other than the water validation built into Coot of course, you could also
try Whatcheck.
>
> HTH,
>
> Paul.
>

-- 
Dayana Nisbar

Re: [ccp4bb] Akta vs HPLC

[aaleshin]

Back in Iowa State University we used Waters HPLC for protein purification 
during many years without noticeable damage to the stainless steel tubings. But 
Dan was right about the pumps, someone in the lab forgot to flush the high salt 
pump with water after its use  and damaged the pump...

Alex

On May 29, 2012, at 5:14 PM, Daniel Anderson wrote:

> Hi, Ho,
> 
> Your question has a lot of variables.
> 
> "HPLC" columns should not be used on the Akta within my field of view 
> because the Akta within my field of view does not have gradual pump 
> acceleration and deceleration. "HPLC" columns can be damaged by sudden 
> changes in pressure or composition.
> 
> The "HPLC" within my field of view has wetted stainless steel surfaces 
> and the mobile phase should not contain chloride ion or reductant. 
> Chloride ion would accelerate corrosion of the stainless steel (and 
> result in metal ions in the protein). Reductant would strip off the 
> "passivation" (during maintenance I soak the stainless parts in nitric 
> acid to keep them stainless) later resulting in corrosion.
> 
> The Waters sales representative once told me that the pumps have to be 
> salt-free and methanol-flushed at the end of every working day. Good 
> luck implementing that policy.
> 
> -Dan
> 
> Ho Leung Ng wrote:
>> Hello,
>> 
>> My Akta Purifier is being repaired, and I'm thinking about 
>> borrowing a colleague's HPLC in the interim. What makes the Aktas 
>> different from HPLCs? I've used HPLCs for purifying small molecules 
>> and peptides but not proteins. Anything I should be careful about 
>> regarding keeping the machines, columns, and proteins happy?
>> 
>> 
>> Thank you,
>> Ho
>> 
>> Ho Leung Ng
>> University of Hawaii at Manoa
>> Assistant Professor, Department of Chemistry
>> h...@hawaii.edu 

Re: [ccp4bb] Akta vs HPLC

[Dima Klenchin]

What makes the Aktas different from HPLCs?


Nothing. Akta Purifyer *is* HPLC.

Dima

Re: [ccp4bb] Akta vs HPLC

[Daniel Anderson]

Hi, Ho,

Your question has a lot of variables.

"HPLC" columns should not be used on the Akta within my field of view 
because the Akta within my field of view does not have gradual pump 
acceleration and deceleration. "HPLC" columns can be damaged by sudden 
changes in pressure or composition.


The "HPLC" within my field of view has wetted stainless steel surfaces 
and the mobile phase should not contain chloride ion or reductant. 
Chloride ion would accelerate corrosion of the stainless steel (and 
result in metal ions in the protein). Reductant would strip off the 
"passivation" (during maintenance I soak the stainless parts in nitric 
acid to keep them stainless) later resulting in corrosion.


The Waters sales representative once told me that the pumps have to be 
salt-free and methanol-flushed at the end of every working day. Good 
luck implementing that policy.


-Dan

Ho Leung Ng wrote:

Hello,

 My Akta Purifier is being repaired, and I'm thinking about 
borrowing a colleague's HPLC in the interim. What makes the Aktas 
different from HPLCs? I've used HPLCs for purifying small molecules 
and peptides but not proteins. Anything I should be careful about 
regarding keeping the machines, columns, and proteins happy?



Thank you,
Ho

Ho Leung Ng
University of Hawaii at Manoa
Assistant Professor, Department of Chemistry
h...@hawaii.edu 

[ccp4bb] Akta vs HPLC

[Ho Leung Ng]

Hello,

 My Akta Purifier is being repaired, and I'm thinking about borrowing a
colleague's HPLC in the interim. What makes the Aktas different from HPLCs?
I've used HPLCs for purifying small molecules and peptides but not
proteins. Anything I should be careful about regarding keeping the
machines, columns, and proteins happy?


Thank you,
Ho

Ho Leung Ng
University of Hawaii at Manoa
Assistant Professor, Department of Chemistry
h...@hawaii.edu

Re: [ccp4bb] find water in coot

[Paul Emsley]

On 29/05/12 19:49, Dayana Nisbar wrote:

I need help with finding water in my protein structure using Coot.

I tried to find water with peaks above 1.6 sigma for both the 2Fo-Fc and 
mFo-DFc maps.

The result were 253 water molecules found for 2Fo-Fc map and 563 water 
molecules found for mFo-DFc map.

My question is

1) Why  is it the number of water molecules are different?


Because the map you are searching are different.  The peaks have 
different positions, shape and distance to protein atoms.



2) Which map should we use to correctly place the water molecules?


I prefer the 2Fo-Fc style map.  You could create a weighted average of 
these maps if you wish.



3) What is the sigma cut-off for finding water?


How "deep" do you want to delve into you map?  There is a lot of shape 
at 0.1 rmsd - do you want to model that?  (Most people do not).  Most 
people are happy to model density features around 1 rmsd for 2FoFc-style 
map and around 3 rmsd for the difference map.  (Not to say, of course, 
that 1 rmsd has much meaning for 2FoFc-style map, but as a rule of 
thumb, it is not bad at about 1.8-2.2A and solvent content 55+/-7% in my 
experience).



4) How can I validate these water molecules?



Other than the water validation built into Coot of course, you could 
also try Whatcheck.


HTH,

Paul.

[ccp4bb] find water in coot

[Dayana Nisbar]

Dear all, 

I need help with finding water in my protein structure using Coot. 

I tried to find water with peaks above 1.6 sigma for both the 2Fo-Fc and 
mFo-DFc maps.

The result were 253 water molecules found for 2Fo-Fc map and 563 water 
molecules found for mFo-DFc map.

My question is

1) Why  is it the number of water molecules are different?

2) Which map should we use to correctly place the water molecules?

3) What is the sigma cut-off for finding water?

4) How can I validate these water molecules?

Fyi, my crystal structure have 382 amino acid and 2 molecules per asymmetric 
unit.

[ccp4bb] Moleculardimensions kits

[Barbara Medagli]

Dear all,
This is Barbara Medagli, working in the structural biology 
lab in Italy

Surfing in the molecular dimensions web site
I found this two screens: MIDAS and ProPlex.
I was thinking in buy them as I have to order other
items to this company
Some of you already used those kits?
Any experience with them?
Thanks for the help



Barbara Medagli, PhD
Structural Biology Lab
Sincrotrone Trieste SCpA
S.S. 14, km 163.5, Loc. Basovizza
34012 Trieste/Italy
phone +39040 3758807/8537
fax +39040 3758029

Re: [ccp4bb] P321 space group reindex problem

[Ian Tickle]

Hi Qixu

Whether it's valid to simply swap h and k depends on whether you have
anomalous data (I assume you don't have any phases at this stage).  If
not there's no issue with inverting the hand, but if you do then you
must either remove the anomalous data to avoid confusing yourself and
others later on, or change the sign of the anomalous differences (or
swap F-/F+ and/or I-/I+ as appropriate).

You swapped h and k i.e. (h, k, l) to (k, h, l): taken with the
equivalent reflection (k, h, -l) this gives (h, k, -l) which is
exactly the index transformation that I derived (see my previous
email).  You could have done the same thing with reindex using h,k,-l
and the LEFT keyword (in fact I would stick to well-tried programs!).
So with my proviso about anomalous data above, what you have done is
completely correct and the R factor of 29% that you got for derivative
2 (assuming I've understood you correctly) supports this.

I can't explain why pointless appears not to have worked, Phil is the
person to ask about that.

Cheers

-- Ian

On 29 May 2012 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  写道：
>
>> 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 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 wou

Re: [ccp4bb] P321 space group reindex problem

[Phil Evans]

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  写道：
> 
>> 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 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 >>   > wrote:
 In different datasets of P321 crystals, when you index them
>>>   separately, the hand may be different and you may need to invert

Re: [ccp4bb] P321 space group reindex problem

[Qixu Cai]

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  写道：

> 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 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 >> 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
>>
>> >
>> >
>> >
>> > On 29 May 2012, at 

Re: [ccp4bb] P4132 vs. F23

[Andrey Lebedev]

Hi Mike.

I would be more careful about "incorrect" space group. Yes, sometimes 
auto-indexing gives strange results.
However, in your case two sets of crystals differ by two factors, diffraction 
quality and space group.
Therefore it seems more likely that you have two crystal forms.
Could you please send me log-files from pointless or ctruncate? Then I would be 
able to say something more definite.

Regards

Andrey

On 28 May 2012, at 08:46, Mike John wrote:

Hi, All,

we got many datasets from crystals of our protein. when the crystal has high 
quality, it will be indexed as F23 (correct space group). While diffracting 
poorer, it will be indexed as incorrect space group  P4132. The crystals are 
twined. My question is:
Given twinning, why the correct space group F23 will be indexed as an incorrect 
space group P4132 for most of our crystals (most crystals has poorer quality)? 
Theoretical analysis of twin operator and symmetry operator to connect F23 and 
P4132 would be highly appreciated. Thanks

Mike

Re: [ccp4bb] P321 space group reindex problem

[Ian Tickle]

George

The CCP4 programs (I can't speak for others) involved with isomorphous
replacement, i.e. scaling, FFT for difference Pattersons & Fouriers,
and heavy-atom refinement (e.g. MLPHARE), mostly require that the
native data and that of all the derivatives be not only in the same
a.u. but sorted identically, so the preceding programs such as CAD go
to a lot of trouble to ensure this.

Cheers

-- Ian

On 29 May 2012 14:29, George Sheldrick  wrote:
> Which programs require that the data be the 'standard' a.u.? None of mine
> require this.
>
> George
>
>
> On 05/29/2012 03:44 PM, Ian Tickle wrote:
>>
>> 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
>
>
> --
> Prof. George M. Sheldrick FRS
> Dept. Structural Chemistry,
> University of Goettingen,
> Tammannstr. 4,
> D37077 Goettingen, Germany
> Tel. +49-551-39-3021 or -3068
> Fax. +49-551-39-22582

Re: [ccp4bb] P321 space group reindex problem

[Phil Evans]

Although there is no need for a "standard" reciprocal asu, it is convenient to 
have all your datasets in the same convention when it comes to comparing and 
combining different isomorphous datasets (ie to do it once rather than every 
time you compare them). It doesn't matter what the "standard" is as long as it 
is consistent

Reading Ian's Email more carefully, it is true that eg in 321 the reindexing 
k,h,-l may take it out of the standard asu, and need an inversion operator to 
put it back. In that case, Pointless (and Reindex) do reduce the hkl to the asu 
and swap anomalous columns, and pointless will also invert phase columns etc

>> No the hand-preserving transformation in 321 is (k,h,-l)
> 
> But that's an equivalent of the space group so it won't transform from
> the alternate setting (-h, -k, l). It will just give you a _different_
> a.u. of the _same_ setting.  We need the _same_ a.u. of the
> _different_ setting!


Apologies, you are right, for 321 the reindexing operator is (-h,-k,l). But 
Pointless will do it correctly (I believe!)

Phil


On 29 May 2012, at 14:29, George Sheldrick wrote:

> Which programs require that the data be the 'standard' a.u.? None of mine 
> require this.
> 
> George
> 
> On 05/29/2012 03:44 PM, Ian Tickle wrote:
>> 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
> 
> -- 
> Prof. George M. Sheldrick FRS
> Dept. Structural Chemistry,
> University of Goettingen,
> Tammannstr. 4,
> D37077 Goettingen, Germany
> Tel. +49-551-39-3021 or -3068
> Fax. +49-551-39-22582

Re: [ccp4bb] P321 space group reindex problem

[Ian Tickle]

Phil,

On 29 May 2012 15:09, Phil Evans  wrote:

> No the hand-preserving transformation in 321 is (k,h,-l)

But that's an equivalent of the space group so it won't transform from
the alternate setting (-h, -k, l). It will just give you a _different_
a.u. of the _same_ setting.  We need the _same_ a.u. of the
_different_ setting!

Cheers

-- Ian

Re: [ccp4bb] P321 space group reindex problem

[George Sheldrick]

Which programs require that the data be the 'standard' a.u.? None of 
mine require this.


George

On 05/29/2012 03:44 PM, Ian Tickle wrote:

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


--
Prof. George M. Sheldrick FRS
Dept. Structural Chemistry,
University of Goettingen,
Tammannstr. 4,
D37077 Goettingen, Germany
Tel. +49-551-39-3021 or -3068
Fax. +49-551-39-22582

Re: [ccp4bb] P321 space group reindex problem

[Phil Evans]

As Graeme points out this is the easy way to do this

Pointless will (now) correctly handle anomalous and phase columns in a 
reindexing

Phil


On 29 May 2012, at 09:57, Graeme Winter 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  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

Re: [ccp4bb] P321 space group reindex problem

[Phil Evans]

On 29 May 2012, at 15:02, Ian Tickle wrote:

> Phil,
> 
> On 29 May 2012 14:08, Phil Evans  wrote:
>> NO do NOT invert the hand. If you do you will end up with left-handed 
>> helices etc
> 
> Surely not if you take care to also change the signs of the anomalous
> differences?

I suppose that's true (I think) but it's no harder to do it properly (ie 
preserving the hand


> 
>> The alternative indexing systems all need to preserve the right-handed axis 
>> system imposed by the data integration program (eg k,h,-l)
>> 
>> The ONLY time it is valid to invert the hand is if the indexing/integration 
>> program itself inverted the hand due to a bug (this has been know, but not 
>> for a long time)
> 
> Assuming I've got the correct transformations and a.u. in P321 it's
> only possible to re-index from the alternate setting if the hand is
> inverted (and the anomalous data & any phase columns converted).
> 


No the hand-preserving transformation in 321 is (k,h,-l)

Phil



> Cheers
> 
> -- Ian

Re: [ccp4bb] P321 space group reindex problem

[Ian Tickle]

Qixu, yes obviously any sub-group is a possible indexing (all the way
down to P1 !).  You need to compare your Rpims etc.

Cheers

-- Ian

On 29 May 2012 15:03, Qixu Cai  wrote:
> P3 is another possible alternate indexing? is that correct?
>
>
>
> 2012/5/29 Ian Tickle 
>>
>> 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  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
>> >
>> >
>> >
>> > 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  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  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?
>> 
>

Re: [ccp4bb] P321 space group reindex problem

[Qixu Cai]

P3 is another possible alternate indexing? is that correct?


2012/5/29 Ian Tickle 

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

Re: [ccp4bb] P321 space group reindex problem

[Ian Tickle]

Phil,

On 29 May 2012 14:08, Phil Evans  wrote:
> NO do NOT invert the hand. If you do you will end up with left-handed helices 
> etc

Surely not if you take care to also change the signs of the anomalous
differences?

> The alternative indexing systems all need to preserve the right-handed axis 
> system imposed by the data integration program (eg k,h,-l)
>
> The ONLY time it is valid to invert the hand is if the indexing/integration 
> program itself inverted the hand due to a bug (this has been know, but not 
> for a long time)

Assuming I've got the correct transformations and a.u. in P321 it's
only possible to re-index from the alternate setting if the hand is
inverted (and the anomalous data & any phase columns converted).

Cheers

-- Ian

Re: [ccp4bb] P321 space group reindex problem

[Ian Tickle]

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

Re: [ccp4bb] P321 space group reindex problem

[Phil Evans]

NO do NOT invert the hand. If you do you will end up with left-handed helices 
etc

The alternative indexing systems all need to preserve the right-handed axis 
system imposed by the data integration program (eg k,h,-l)

The ONLY time it is valid to invert the hand is if the indexing/integration 
program itself inverted the hand due to a bug (this has been know, but not for 
a long time)

Phil

On 29 May 2012, at 12:55, Mark J van Raaij 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
> 
> 
> 
> 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  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  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

Re: [ccp4bb] P321 space group reindex problem

[Qixu Cai]

Thanks for your help.

How to override the warning?


2012/5/29 Mark J van Raaij 

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

Re: [ccp4bb] P321 space group reindex problem

[Qixu Cai]

Thanks for your help.

How to use CAD to invert the hand?


2012/5/29 Ian Tickle 

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

[ccp4bb] XDSAPP - A new GUI for data processing using XDS

[Müller , Uwe]

Dear CCP4BB users,

we would hereby like to introduce XDSAPP, a GUI for the easy and
convenient processing of diffraction data sets using XDS (see also
Krug et al. (2012). J. Appl. Cryst. 45, 568-572).

XDSAPP automates the data processing, generates plots of various
data set statistics and produces intensity files suitable for further
analysis using CCP4, SHELX and CNS.

XDSAPP has the following features:
  - detector support for Rayonics MX-225, MARCCD-165 mm, PILATUS 6M  and ADSC 
Quantum Q315r
  -  Successfully tested on various Linux platforms
  - Full XDS-multiprocessor support
  -  Space group determination using pointless
  -  Twinning and pseudo-translation analysis using phenix.xtriage and sfcheck  
(CCP4 and PHENIX programs must be installed separately)
  -  Life graphics during Integration
  -  Graphical output of statistics of CORRECT and XDSSTAT (XDSSTAT must be 
installed separately)
  -   All XDS output files (.pck, .cbf, .LP) available for viewing within the 
GUI
  -   Automatic multi-crystal processing
  -  Output files in mtz, hkl and cv format

XDSAPP is freely available for academics.

More information on XDSAPP including download instructions can be found at:
http://www.helmholtz-berlin.de/bessy-mx


Uwe Mueller, Manfred S. Weiss and Michael Krug


Dr. Uwe Mueller
Soft Matter and Functional Materials
Macromolecular Crystallography (BESSY-MX) | Group leader
Elektronenspeicherring BESSY II
Albert-Einstein-Str. 15, D-12489 Berlin, Germany

Fon: +49 30 8062 14974
Fax: +49 30 8062 14975
url: www.helmholtz-berlin.de/bessy-mx
email:u...@helmholtz-berlin.de




Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. 
Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

Re: [ccp4bb] P321 space group reindex problem

[Mark J van Raaij]

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



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

Re: [ccp4bb] P321 space group reindex problem

[Ian Tickle]

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

Re: [ccp4bb] MAD data process problem

[Tim Gruene]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Qixu Cai,

MAD phasing is based on the comparison of Bijvoet-pairs, i.e. I(hkl)
with I(-h-k-l), both within one data set and between data sets.
Therefore you might get better results if your integration program does
not assume Friedel-pairs to have identical intensities, even though
the difference is probably only marginal (integration programs do not
merge data).
So it is safest click on 'anomalous' for all data sets involved .

Tim

On 05/29/12 11:11, Qixu Cai wrote:
> Dear all,
> 
> Sorry for the question from MAD beginner.
> 
> When we process the MAD datasets, including the peak-data,
> edge-data and remote-data, which datasets need to be process with
> anomalous?
> 
> I know peak-data obviously need data processing with anomalous, but
> what about edge-data and remote-data when we want to use MAD
> method?
> 
> Thank you very much!
> 
> Best wishes,
> 
> Qixu Cai
> 

- -- 
- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen

GPG Key ID = A46BEE1A

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPxJfaUxlJ7aRr7hoRAm3EAKCKkyvT8z0wg6MFjflkHkiq8RR5GQCgyvF3
lOIOLypSzCcN3N6OR/3NcC8=
=m6ax
-END PGP SIGNATURE-

Re: [ccp4bb] MAD data process problem

[Laurent Maveyraud]

Hi,

when processing MAD data, all wavelength should be processed without 
enforcing the Friedel's law... If you look at your fluorescence 
spectrum, you will see that you have anomalous signal for the peak 
(obviously) for the high energy remote and even forh the inflexion point.


For example, in the case of Se-MAD :
peak : f'=-6,  f''-8
inflexion : f'=-11, f''= 4
high remote : f'= -4, f''= 4

the low energy remote is the one with the weakest anamalous signal, 
close to 0 in the case of Se...


hope this helps


laurent

Le 29/05/2012 11:11, Qixu Cai a écrit :

Dear all,

Sorry for the question from MAD beginner.

When we process the MAD datasets, including the peak-data, edge-data and
remote-data, which datasets need to be process with anomalous?

I know peak-data obviously need data processing with anomalous, but what
about edge-data and remote-data when we want to use MAD method?

Thank you very much!

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 BiologieStructurale   et   Biophysique
BP 64182  -  205 rte de Narbonne  -  31077 TOULOUSE FRANCE
Tél: +33 (0)561 175 435   Fax : +33 (0)561 175 994
--

[ccp4bb] MAD data process problem

[Qixu Cai]

Dear all,

Sorry for the question from MAD beginner.

When we process the MAD datasets, including the peak-data, edge-data and 
remote-data, which datasets need to be process with anomalous?


I know peak-data obviously need data processing with anomalous, but what 
about edge-data and remote-data when we want to use MAD method?


Thank you very much!

Best wishes,

Qixu Cai

Re: [ccp4bb] P321 space group reindex problem

[Graeme Winter]

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

Re: [ccp4bb] P321 space group reindex problem

[Laurent Maveyraud]

Hi,

as reindex tells you, if you change h k l to h k -l, you are changing 
the hand of your system, which is not allowed.

In P321 group, you only have two possible indexations :
h k l and k h -l (note that h and k are switched).

You have a good explanation on indexation problem on the CCP4 web site :
http://www.ccp4.ac.uk/dist/ccp4i/help/modules/appendices/reindexing.html

hope this helps

laurent

Le 29/05/2012 10:48, Qixu Cai a écrit :

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 BiologieStructurale   et   Biophysique
BP 64182  -  205 rte de Narbonne  -  31077 TOULOUSE FRANCE
Tél: +33 (0)561 175 435   Fax : +33 (0)561 175 994
--

[ccp4bb] P321 space group reindex problem

[Qixu Cai]

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