Print

Print


By default I believe for most crystallographic applications, the hierarchy is:the symmetry operators, but if absent the SG name (and this can be P21 21 2 or P 21 2 21 or whatever) , but that is absent and you are lazy you can give the SG number.. And that can deal to confusion  and should be used with care, as you all have pointed out..

MX crystallograohers have never been keen on the rigid application of cell dimension rule a<b<c 
There are cases where you may want to override this - possibly to fit against a known crystal form, etc 


On 3 October 2014 18:58, Ian Tickle <[log in to unmask]> wrote:


(a) The IUCr has, in its wisdom, decided to use the Hall space group symbols to settle the matter. See International Tables for Crystallography, Vol. B (2001), Chapter 1.4, Appendix 1.4.2 and Acta Cryst. (1981). A37, 517-525. These are obligatory input for CheckCIF as part of small molecule verification.  'P 21 21 21' becomes 'P 2ac 2ab' and 'P 21 2 21' becomes equally logically  'P 2ac 2ac'. Fortunately for the users, SHELXL-2014 derives the Hall symbols from the symmetry operators.

I agree that would make a lot more sense but it's taken many years to get to where we are now so I can't see this happening any time soon!

(b) Isn't it time to introduce the 'R 3' or 'H 3' or 'R 3 :H' issue again?

Yes by all means: the H cell in ITC (triple cell) means something completely different from the PDB idea of H cell, so it's the PDB we have to tackle.  But again, realistically is it going to happen?

(c) As pointed out already, small molecule crystallographers never have this problem because the coordinates of the general position are used to define the space group symmetry unambiguously, in conventional settings or otherwise. Ian's argument that there could be too much to type in for cubic space groups is irrelevant, because the list is always generated by a program (e.g. XPREP or its clones).

I assume that the Hall symbol unambiguously defines the list of g.e.p.s (if it doesn't then what use is it?).  Assuming that it does then why not use it in place of the list and look up the g.e.p.s from a file (e.g. syminfo.lib)?  As I said before, comparing lists of g.e.p.s seems to be overkill and prone to errors (and in fact I think there have been bugs in the CCP4 implementation).  Simple comparison of the Hall symbols would appear to be a lot less error-prone!

Cheers

-- Ian

George




On 10/03/2014 05:13 PM, Ian Tickle wrote:

Hi Kay

On 2 October 2014 15:04, Kay Diederichs <[log in to unmask]> wrote:

Once again, citing from ITC Vol A Table 9.3.2 (p. 747 in my 1995 edition) , these "conventions refer to the cell obtained by the transformations from Table 9.3.1. They have been chosen for convenience in this table". To me, this indicates that a<b<c _could_ be obtained _if_ one were to transform. But the question is: why would one want to transform? I don't see "sticking to the original indexing" as a convincing convenience.

I'm sorry, unfortunately my edition of ITC-A (5th Ed., 2002) is later than yours (4th Ed.) and I have been unable to get hold of a copy of the edition that you refer to.  In my edition the table equivalent to your 9.3.2 seems to be 9.3.4.1 on p.758 and there doesn't seem to be a table equivalent to your 9.3.1 (the only other table in that section is 9.3.5.1 but that doesn't seem to be relevant).  Also I am unable to match up the text that you quote with what I see in my edition: it seems to be completely different.  So it's very difficult to comment.  According to the Foreword "The present 5th Edition is much more extensively revised than any of its predecessors ..." so I can only assume that the text that you quote was considered unclear and was removed.  But I agree that if one is concerned with a specific structure without reference to any other structure, why would one want to transform anything?  It makes no sense.  The conventional setting is selected according to table 9.3.4.1, end of story.

My copy of ITC Vol A says (p 41) about Table 3.2: "the 'standard' space group symbols ... are printed in bold face". The Table has "P 21 21 2" (18) and "P 2 2 21" (17) in bold face. There is no ambiguity here.

Again I'm sorry but I don't see that text in my edition (p.41 is just a list of references for Chap. 2) and I can't find the corresponding section in my Edition.  However I do agree that the standard symbol for each space group is printed in bold face in the top-left corner of each double-spread page dealing with that space group (also in smaller type in the top-right corner).  Perfectly true observation I agree but how is it relevant?  The 230 standard symbols are the names of the 230 equivalence classes defined on the complete set of possible alternate settings for the equivalence relations consisting of the possible rotations and/or translations relating those alternate settings.  Since they only serve as labels one could equally well have chosen the ordinals 1 through 230 (which are actually given equal prominence to the names).

The important point is that the standard symbol is only the _name_ of the equivalence class and that this is not sufficient for dealing with crystal structures and calculating structure factors etc.: one must specify which element of that class, i.e. from the subset of possible unique _settings_ that are members of that class, to use.  For example in the 5th Ed. the 10 possible settings for standard symbol C2 are shown, with the full H-M symbols C121, A121, I121, A112, B112 etc.  So e.g. A121 is one of the allowed conventional settings in the equivalence class C2.  Notice that the standard symbol C2 is _not_ a full H-M symbol: it doesn't need to be, since it's only a name and it doesn't need to carry any information.  Its only requirement is that it's unique among the 230 equivalence classes.  Similarly the page for standard symbol P2221 shows the possible settings (at least in my Ed.) P2221, P2212 and P2122.  In this case the standard symbol happens to be the same as one of the full H-M symbols of the alternate settings but that's not a requirement, any unique name would have done equally well.  Also in the setting P2221 there obviously remains an ambiguity concerning the assignment of the a and b axes.  How is that resolved?  You will probably say a<b but ITC doesn't specify that as a condition anywhere, it just says "a<b<c", not "a<b<c unless it's P2221 or P21212 when it's a<b" (the first condition doesn't require exceptions).

Have you considered the fact that not all possible alternate settings are listed for all space groups?  For example no trigonal, tetragonal or hexagonal settings have a or b unique (you can find many other examples in the monoclinic & orthorhombic systems, e.g. there are no B settings in orthorhombic).  Why is that?  What's so special about the settings that are listed that doesn't apply to all the ones not listed?  You can be sure it's by very careful design since printing space was at a premium when the tables were first published (I spent my first post doc. at the Laboratorium voor Struktuurchemie at the Rijksuniversiteit Groningen at the same time Dirk Fokkema was there: he wrote the software for the computer-driven typesetting of the main Vol. A table of space groups for his Ph.D. thesis; we had a number of discussions about space groups and I can assure you that the table was very carefully designed!).  The answer is that the settings listed are strictly those that satisfy the requirements of the rules on conventional cells in table 9.3.4.1, no more, no less.  The appropriate setting is selected from the members of the equivalence class of the space group in question according to those rules.

Switching the default in POINTLESS from "SETTING CELL-BASED" to "SETTING SYMMETRY-BASED" would make me happy, but more importantly, would avoid a lot of problems.

Maybe the answer is to fix the problem with pointless that you highlighted originally, i.e. it's apparently reporting the wrong space group in the log file!  Actually extracting stuff from log files is a very bad idea: log files are not guaranteed to remain the same across different versions of the program!  I learnt that the hard way!  Doesn't pointless output an XML file, or you could just read the MTZ file header.  That's what I do, it's much safer.

Cheers

-- Ian


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