Dear Ian,

     Yes, the expression "lattice mode" I used is synonymous with "centring
type". The choice of a rhombohedral vs. a hexagonal cell would be a choice
of centring type, whereas the choice of obverse vs. reverse would be a
choice of setting. A clear operational difference between the two is that a
change of centring type affects "reflection conditions" (i.e. introduces new
ones or removes existing ones) whereas a change of setting doesn't affect
them. Like you I would be sorry to see a word as bland as "description" be
given a precise and structured meaning of the kind we are talking about: we
need both centring type and setting, not some amalgamation of them.

     As for the question of conventions regarding cells and unique axes, we
have corresponded on this topic before. It should be remembered that the 230
distinct entities listed in the standard classification are space-group
TYPES, i.e. what one gets when taking into account every possible way in
which sets of lattice-preserving orthogonal transformations can be viewed as
equivalent. This includes reduction through changes of setting (in group-
theoretic parlance: under the action of the normaliser), and it so happened
that instead of giving a space-group type a separate name, one chose a
particular space group of that type (unavoidably, with some arbitrariness
that the word "convention" tries to make more palatable) as its
"representative" - hence the tautologically conventional nature of the
conventions, as you point out. Much discontent has been directed at poor
P21212, as if it had been granted an unjustified privilege over P22121 and
P21221; while in fact P21212 was singled out only as the "canonical
representative" of its space-group type, to which the others also belong,
being equivalent to it by a change of setting. Here, it is the confusion of
terminology, particularly in software where we used to ask for the name of a
space-group *type* (i.e. something to be chosen among 230 possibilities)
while at the same time expecting to be given a set of integer matrices and
fractional translations defining a specific space group within that type,
that has been (at least partly) responsible for the problem.


     With best wishes,
     
          Gerard.

--
On Tue, Jul 31, 2012 at 12:28:43PM +0100, Ian Tickle wrote:
> Dear Gerard
> 
> Your point concerning my admittedly somewhat cavalier usage of the
> term 'setting' in the R23:r vs R23:h context is well taken, however I
> would point out that a) I'm not the first to use this terminology
> (e.g. the CCN article I referred to talks about "triple-cell
> settings"), and b) ITC doesn't use the specific term 'lattice mode'
> either, though it does use 'centring type' which I guess means the
> same thing?  It would clearly be nice to have a single term that
> encapsulates both concepts, otherwise what are we to call, for
> example, the symbol R32:r - does it define a setting or a centring
> type?
> 
> In ITC the rhombohedral/hexagonal dichotomy is dealt with by assigning
> a property called alternatively 'centring type' and 'description'; the
> first is too specific for what we want, the second it seems to me
> rather too bland and general.  Either way it would appear that R32:r
> is both a symbol for the setting in the context of obverse vs reverse
> rhombohedral settings (conventionally the obverse is chosen so
> presumably the symbol R32:r applies only to that setting, otherwise
> it's ambiguous), and a symbol for the centring type in the context of
> rhombohedral vs hexagonal cells!  However 'description' does seem to
> be the common denominator term: it is used in ITC to indicate both
> settings and centring types - but as I said it does seem rather bland
> ('space group description' could mean almost anything!).  As you
> indicate, for practical purposes getting a consistent vocabulary would
> seem to be of lesser importance than getting a consistent
> nomenclature.
> 
> On the question of primitive vs centred monoclinic lattice types, I
> would point out that in ITC unique axis 'a' settings are also not
> considered to be candidates for the conventional cell, though 'b' and
> 'c' settings are.  So self-evidently not all possible 'descriptions'
> are considered to be conventional and the subset listed in ITC is
> merely a matter of convention (a tautology if ever there was!).
> 
> Cheers
> 
> -- Ian
> 
> 
> 
> On 30 July 2012 17:55, Gerard Bricogne <[log in to unmask]> wrote:
> > Dear Ian,
> >
> >      I made a modest contribution to this discussion a long time ago, and I
> > will only limit myself to one point.
> >
> >      I think you may be confusing "setting" and "lattice mode". A change of
> > setting is performed by an integer matrix with determinant 1 (a "unimodular"
> > matrix) whereas a change of lattice mode involves two mutually inverse
> > integer matrices with determinants (mutually inverse, of course) different
> > from 1.
> >
> >      The case of R32 and H32 seems to stick out like a sore thumb because we
> > never use the primitive-lattice versions of the centered-lattice space
> > groups in the monoclinic, orthorhombic and tetragonal classes - and yet they
> > exist! The problem with them is that e.g. 2-fold axes are represented by
> > non-diagonal matrices that are somehow thought to be an eyesore, so we
> > sacrifice mathematical rigour (the theory of "arithmetic classes") to the
> > comfort of having a 2-fold axis represented by the familiar diagonal matrix
> > with one 1 and two -1 on it. The matrices that would reindex those primitive
> > lattices to the usual centered ones would have determinants 2 or 4 in one
> > direction, and 1/2 or 1/4 in the other. However, as we never see these
> > representations of "centered" space groups in a primitive lattice basis, we
> > are startled when we come to the trigonal class. Here, the 3-fold axis has
> > two distinct representations by integer matrices: one in which the three
> > axes undergo a circular permutation (so they have to be of equal lengths and
> > separated by equal angles), and the other in which one axis (z) is
> > invariant, and the 3-fold symmetry is represented by a 120-degree rotation
> > in the (x,y) plane. These two representations cannot be mapped into each
> > other by means of a unimodular matrix: if one reindexes one representation
> > into the other, the determinant is 3 in one direction and 1/3 in the other.
> > In this case, it is a matter of opinion which representation of a 3-fold
> > axis has the greatest aesthetic merit, so the two possibilities are in use,
> > unlike the poor non-diagonal 2-fold axis representations that no one wants
> > to see.
> >
> >      It is a matter of convention and vocabulary whether one calls these two
> > modes of indexing the rhombohedral and hexagonal "lattice modes", or calls
> > them "settings": one thing is certain, and that is that the mathematical
> > phenomenon in question is of a different kind from the reindexing of P21212
> > into P22121 with which you draw a parallel.
> >
> >      At least this is what my distant memories of space-group theory seem to
> > be telling me :-)) .
> >
> >
> >      With best wishes,
> >
> >           Gerard.
> >
> > --
> > On Mon, Jul 30, 2012 at 04:23:02PM +0100, 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.
> >> >>
> >> >>
> >> >

-- 

     ===============================================================
     *                                                             *
     * Gerard Bricogne                     [log in to unmask]  *
     *                                                             *
     * Global Phasing Ltd.                                         *
     * Sheraton House, Castle Park         Tel: +44-(0)1223-353033 *
     * Cambridge CB3 0AX, UK               Fax: +44-(0)1223-366889 *
     *                                                             *
     ===============================================================