Hi Phil,
as far as I understand, you are stating a consensus ("do not use
numbers, do use the Hermann-Mauguin-symbols), rather than a problem. The
problem seems that the artificial space group numbers 1018, etc.,
contained in symop.lib, do not follow the consensus and thus cause
irritation.Best, Tim On 10/02/2014 04:46 PM, Phil Evans wrote: > I'm still a bit confused about why there is a problem: why use SG numbers? "P > 2 21 21" (or indeed "P22121") is clear and unambiguous. There is no need to > use the numbers (and certainly not the weird CCP4 numbers like 3018 which I > was trying to hide in Pointless > > Phil > > On 2 Oct 2014, at 15:04, Kay Diederichs <[email protected]> > wrote: > >> On Thu, 2 Oct 2014 11:58:42 +0100, Ian Tickle <[email protected]> wrote: >> >>> Hi, we shouldn't be using numbers at all (CCP4-style or otherwise, since >>> no-one else outside the MX community uses these). We should be using the >>> unique full Hermann-Mauguin symbol, since the 'standard setting' space >>> group number in IT obviously does not uniquely define the setting, and it's >>> the setting that matters. Note that the standard setting symbol P2221 >>> means 'either P2122 or P2212 or P2221' according to the a<=b<=c convention >>> (this is universal amongst the crystallography communities), so you still >> >> 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. >> >>> have to define the setting if you refer to the standard symbol. I'm aware >> >> 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. >> >>> that some software uses the list of general equivalent positions to define >>> the space group but IMO that's overkill. If I wan't to talk about space >>> group F432 you can't expect me to recite the list of 96 g.e.p.s! - the H-M >>> symbol is sufficient. There are of course other cases besides P2221 where >>> the setting is ambiguous (e.g. C2/A2/I2 and various cases of origin >>> shifting), so using the correct symbol for the setting is critical. >>> >>> The most important features of any convention are a) that it's documented >>> in an 'official' publication (i.e. not informal such as software >>> documentation, otherwise how am I supposed to reference it?), and b) >>> everyone subscribes to it. If you think we should be using a different >>> convention then I want to see the proper documentation for it, with >>> everything spelled out in excruciating detail (so it should be at least as >>> thick as ITC!). It seems to me that ITC fulfils these requirements >>> admirably! >> >> 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. >> >> thanks, >> >> Kay >> >>> >>> Cheers >>> >>> -- Ian >>> >>> On 2 October 2014 10:25, Kay Diederichs <[email protected]> >>> wrote: >>> >>>> On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans <[email protected]> >>>> wrote: >>>> >>>>> Be careful: the International Tables space group number may be ambiguous. >>>> For example sg number 18 may refer to P 21 21 2 or its permuted settings P >>>> 21 2 21 or P 2 21 21, if you follow the "proper" IUCr convention that >>>> primitive orthorhombic space groups have a<b<c >>>> >>>> I would like to point out that there is an alternative interpretation of >>>> the International Tables (Vol A, 4th ed. 1995). In that interpretation >>>> (which e.g. XDS follows) space group 18 has the 'standard' space group >>>> symbol, "P21 21 2" (bold letters in Table 3.2). This is of course not >>>> ambiguous at all; the pure 2-fold then corresponds to the "c" axis and >>>> there is always a permuation of axes to achieve this. As a result, the axes >>>> are not necessarily ordered such that a<b<c . The latter ordering is just a >>>> "convention" which was "chosen for convenience" and the "convention >>>> refer(s) to the cell obtained by the transformations from Table 9.3.1" >>>> (citing from table 9.3.2) - in other words, the convention is fulfilled >>>> _after_ the transformation (which of course is just order-permuting while >>>> keeping right-handedness) - nothing new here. >>>> >>>> In my understanding, CCP4 developers have (years ago) understood this >>>> "convention" as a "condition", which lead them to invent "CCP4 space group >>>> symbols" 1017 and 2017 as well as 1018, 2018, 3018. This also seems to be >>>> the reason for the default being "SETTING CELL-BASED" in POINTLESS. >>>> >>>> Users of XDS should be aware that by default, POINTLESS therefore permutes >>>> the axes such that a<b<c . This however may lead to space groups 1017 / >>>> 2017 / 1018/ 2018/ 3018 - indicated in the MTZ file, but not in the >>>> POINTLESS log file (last I checked). >>>> >>>> In consequence, XDS will use the space group 17 or 18 (which is what >>>> POINTLESS reports), but the user must provide the correct ordering (which >>>> does not necessarily mean a<b<c) of cell parameters in XDS.INP. The easiest >>>> way, for XDS users, would be to run POINTLESS with the "SETTING >>>> SYMMETRY-BASED" option (I wish the latter were the default because the >>>> default SETTING CELL-BASED has no advantages that I can see). Or they use >>>> the "good old manual way" of inspecting, by eye, the systematic absences >>>> along H00 0K0 00L - this cannot fail. >>>> >>>> To me, "symmetry trumps cell metric" so "SETTING SYMMETRY-BASED" should be >>>> the default. >>>> >>>> I'm harping on this because I have recently seen how a Molecular >>>> Replacement solution was not obtained in space group 18 because of the >>>> misleading (I'd say) ordering a<b<c . >>>> >>>> I'm probably also harping on this because it took me so many years to >>>> discover this failure mode, and I would like to prevent others from falling >>>> into this trap. >>>> >>>> HTH, >>>> >>>> Kay >>>> >>>> >>>> >>>>> >>>>> The space group names are unambiguous (though also watch out for R3 & R32 >>>> which are normally indexed as centred hexagonal, but could be indexed in a >>>> primitive cell) >>>>> >>>>> Phil >>>>> >>>>> >>>>> On 30 Sep 2014, at 13:07, Simon Kolstoe <[email protected]> wrote: >>>>> >>>>>> Dear ccp4bb, >>>>>> >>>>>> Could someone either provide, or point me to, a list of space-groups >>>> relevant to protein crystallography just by space group number? I can find >>>> lots of tables that list them by crystal system, lattice etc. but no simple >>>> list of numbers. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Simon >>>> >>> > -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A
signature.asc
Description: OpenPGP digital signature
