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 <[log in to unmask]> wrote:
>
>> On Thu, 2 Oct 2014 11:58:42 +0100, Ian Tickle <[log in to unmask]> 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 <[log in to unmask]>
>>> wrote:
>>>
>>>> On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans <[log in to unmask]>
>>>> 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 <[log in to unmask]> 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
|