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

Help for CCP4BB Archives


CCP4BB Archives

CCP4BB Archives


CCP4BB@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CCP4BB Home

CCP4BB Home

CCP4BB  July 2012

CCP4BB July 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Space group R32 and H32

From:

Ian Tickle <[log in to unmask]>

Reply-To:

Ian Tickle <[log in to unmask]>

Date:

Mon, 30 Jul 2012 17:36:44 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (277 lines)

Hi Sebastiano

How programs refer to it is irrelevant for the purposes of
publication!  If you want to be precise and stick to the ITC
convention on nomenclature it's "space group R32 in the setting
R32:h", since as I explained it's only the standard symbol R32 which
is generally shown in the main ITC table of space groups; the setting
symbols are not shown in all cases.  However simply calling it 'R32:h'
is also completely unambiguous and acceptable (but calling it 'R32'
most definitely is not!).  For the PDB CRYST1 record you have
(unfortunately) to call it 'H32'.

Hope this clears it up.

-- Ian

On 30 July 2012 17:20, Sebastiano Pasqualato
<[log in to unmask]> wrote:
>
> Hi there,
> at this point I'm confused, at least with respect to one thing.
> If I have a solved a structure in spacegroup #155, with a=b and different
> from c, and alpha=beta=90, gamma=120, this would be reported as R32 in the
> international tables. However programs refers to it as H32.
> What should I report in the (in)famous  "table 1" ?
> Thanks in advance,
> ciao,
> s
>
> On Jul 30, 2012, at 5:23 PM, Ian Tickle wrote:
>
> Without wishing to re-ignite previous discussions on this topic
> (perhaps <FLAME> ... </FLAME> tags would be in order!), I would point
> out that this and similar confusion with other space groups has arisen
> largely from a failure of some programmers (and users!) to fully
> comprehend the important difference between a 'standard symbol' and a
> 'setting symbol' for a space group, no doubt because in many cases
> these are superficially identical, or a least very similar.  This
> point is also made in the Computational Crystallography Newsletter
> article on H3 and H32 that I referenced earlier.
>
> The Hermann-Mauguin symbol (aka 'standard symbol') is unique to a
> space group and crucially is designed to be independent of the setting
> (orientation and/or origin).  It is used to identify a space group
> without reference to the setting, and therefore its main use is to
> provide page headings and index entries in ITC. There exist exactly
> 230 H-M standard symbols for the 230 unique 3D space groups.  The H-M
> standard symbol is the same for all settings of a particular space
> group and therefore cannot be used to define the setting: for that you
> obviously need additional information.
>
> The standard symbol is thus of little or no relevance to practical
> crystallography: for that you must use a setting symbol.  However for
> the majority of space groups only one setting is accepted as
> 'conventional' so in those cases the standard and setting symbols are
> identical; it's only where there are multiple settings that problems
> arise.
>
> A simple analogy might be to say that an object is called 'building'
> and that is also its standard symbol.  It describes the object without
> reference to its orientation or position and so is not relevant to the
> practical problem of defining the view of the building: for that you
> need extra symbols.  For example you might need to specify one of the
> setting symbols 'building (front elevation)', 'building (side
> elevation)' or 'building (plan)'.
>
> So R32 is a H-M standard symbol which corresponds to the 2 alternate
> setting symbols R32:r and R32:h as described in the article.  Plainly
> you can't use the H-M symbol R32 to uniquely specify the setting since
> it is the standard symbol for both the R32:r and R32:h settings.  The
> latter are _not_ H-M symbols: they are ITC extensions of the H-M
> symbol.
>
> For other space groups further confusion has arisen because ITC often
> uses the exact same character string for both the standard symbol and
> one of the corresponding alternate setting symbols.  An obvious
> example is P21212: this is the H-M standard symbol for SG #18 but is
> also one of the 3 ITC setting symbols for P21212, the other two being
> P22121 and P21221.  Perhaps the intention would have been clearer if
> the ITC setting symbols had all been made different from the standard
> symbol, as they are in the R32 case.  For example P21212a, P21212b and
> P21212c would have been equally valid choices for the ITC setting
> symbols but do not express a 'preferred' setting (since there isn't
> one).  Similarly the standard symbol for SG #5 (unique axis b) is C2,
> and the alternate setting symbols are A2, C2 and I2, but they could
> equally well have been (for example) C2a, C2c and C2i, which doesn't
> express a preference for any one of the alternate settings.
>
> Either way, according to the ITC rules, the choice of 'conventional'
> setting for a space group (i.e. the recommended default choice when
> there are no other grounds such as isomorphism with a previously
> determined structure) is made by reference to the unit cell.  For R32
> the conventional cell happens to be the hexagonal one (a = b != c,
> alpha = beta = 90, gamma = 120) with symbol R32:h; for all
> orthorhombic SGs the convention is a < b < c and the setting symbol
> derives from that.
>
> Cheers
>
> -- Ian
>
> On 28 July 2012 22:22, Edward A. Berry <[log in to unmask]> wrote:
>
> Are all the software packages consistent in their (mis)use of these
>
> symbols? Recently I scaled data (scalepack) as R3, imported to ccp4 as H3,
>
> and had to make a link in $ODAT/symm from R32 to H32 (which it turned out to
>
> be).
>
>
>
>
> Ian Tickle wrote:
>
>
> If we're all agreed that ITC(A) is taken as the authority on all
>
> matters of space group symbology (and I for one certainly agree that
>
> it should be), then SG symbol H32 (SG #145:
>
> http://img.chem.ucl.ac.uk/sgp/medium/145bz1.htm) has nothing to do
>
> with R32 (SG #155: http://img.chem.ucl.ac.uk/sgp/medium/155az1.htm)!
>
> According to the Hermann-Mauguin system of nomenclature H32 (more
>
> correctly written as H3_2 where the '_' indicates a subscripted screw
>
> axis) would be the hexagonal-centred (H) lattice setting of P32 (P3_2
>
> in H-M).  H32 as an alternate setting symbol for R32 is a very recent
>
> PDB invention which conflicts with the well-established H-M convention
>
> used throughout ITC.  The ITC symbols for the rhombohedral&  hexagonal
>
>
> axis settings of SG R32 are R32:r and R32:h respectively, i.e. obvious
>
> extensions of the H-M symbols without introducing any conflict with
>
> the existing convention, as the PDB symbol does.  The confusion has
>
> arisen from the failure to distinguish the lattice type (the first
>
> letter of the symbol) from the symbol for the basis system of the
>
> setting (the final letter after the ':').
>
>
> See http://cci.lbl.gov/~rwgk/my_papers/CCN_2011_01_H3_H32.pdf for an
>
> excellent explanation of all this and of the confusion that arises
>
> when programmers ignore established conventions and 're-invent the
>
> wheel' (e.g. SCALEPACK apparently swaps the meaning of the PDB symbols
>
> R32&  H32 and uses R32 for PDB H32 and vice-versa!).
>
>
>
> Cheers
>
>
> -- Ian
>
>
> On 27 July 2012 21:09, Bernhard Rupp<[log in to unmask]>  wrote:
>
>
> H32 indicates the hexagonal obverse setting (as you list) for a R
>
> centered trigonal cell, which is 3x larger than the primitive R32 cell
>
> indexed a=b=c, al=be=ga<>  90. Standard imho is the H32 setting, for which I
>
> will probably get flamed.
>
> The relation between H and R cells is depicted here:
>
>
> http://www.ruppweb.org/Garland/gallery/Ch5/pages/Biomolecular_Crystallography_Fig_5-29.htm
>
>
> This has been discussed and is explained in the ccp4 tutorials and doc
>
> afaik, where you can find more detailed info.
>
>
> For proper format in a journal, I would suggest to adhere to the format
>
> given in the ITC (International tables for Crystallography), I.e. Bravais
>
> Italic, subscripted screw symbols. Note that this is not the format you put
>
> it into most programs - their docs help.
>
>
> You can also try my old space croup decoding program to see general
>
> positions, operators, matrices and other useful stuff.
>
>
> http://www.ruppweb.org/new_comp/spacegroup_decoder.htm
>
>
> HTH, BR
>
>
> -----Original Message-----
>
> From: CCP4 bulletin board [mailto:[log in to unmask]] On Behalf Of
>
> Theresa Hsu
>
> Sent: Friday, July 27, 2012 12:54 PM
>
> To: [log in to unmask]
>
> Subject: [ccp4bb] Space group R32 and H32
>
>
> Dear all
>
>
> I have a confusion on the space group R32 and H32. For a cell parameter
>
> of a = b not equal to c, alpha=beta, not equal to gamma, is it considered as
>
> R32 or H32?
>
>
> I tried searching the mail list archives but it does not help a beginner
>
> crystallographer like me.
>
>
> I also have another basic question. What is the correct way for writing
>
> space groups? Is the Bravais lattice in italic and is there space after
>
> that? Or it does not matter because both are used in literature?
>
>
> Thank you.
>
>
>
>
>
> --
> Sebastiano Pasqualato, PhD
> Crystallography Unit
> Department of Experimental Oncology
> European Institute of Oncology
> IFOM-IEO Campus
> via Adamello, 16
> 20139 - Milano
> Italy
>
> tel +39 02 9437 5167
> fax +39 02 9437 5990
>
> please note the change in email address!
> [log in to unmask]
>
>
>
>
>
>
>

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

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


JiscMail is a Jisc service.

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

For help and support help@jisc.ac.uk

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