Re: [ccp4bb] Space group numbers
Hi Ian, I'm afraid that I will maintain my opinions that - crystallography is elegant and unambiguous and should be kept like that. The ITC even in the latest 2006 incarnation links space group number 17 to P 2 2 21 and 18 to P21 21 2 (see e.g. http://it.iucr.org/Ab/ch7o1v0001/sgtable7o1o018/ but unfortunately this seems to require a license). - throughout crystallography, symmetry is more important than cell metric which means, in the case of space groups 17 and 18, that enforcing of a convention/ convencience/ rule abc will be misleading in (statistically) 2 out of 3 cases, and I have evidence from outside of my group that default application of this has lead to very real problems in structure solution. - extracting information from (reading and trying to understand) a logfile is _exactly_ what a logfile is meant for. I do agree that in your use case it may be helpful to order abc as long as the symmetry is unknown. I also do understand that the H-M symbols allow to describe the different settings, but this is a level of complication that is not necessary to understand for todays's typical crystallographer, because fortunately e.g. the C121 setting is practically uniformly used (and chosen by POINTLESS, as far as I understand) to represent C2 crystals. I just wish the same were true for space groups 17 and 18. Importantly, this would prevent no-one from using a different setting if s/he wishes, but the setting chosen by the software should not depend on the mercy of the cell axes. This is my last message in this meanwhile highly confusing thread. best, Kay Am 03.10.14 um 17:13 schrieb Ian Tickle: Hi Kay On 2 October 2014 15:04, Kay Diederichs kay.diederi...@uni-konstanz.de mailto:kay.diederi...@uni-konstanz.de 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 abc _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
Re: [ccp4bb] Space group numbers
Dear Ian, Kay et al., The omnipotent CheckCIF program that is used to check all small molecule structures submitted to /Acta Cryst./ and many other journals requires (a) the H-M space group name, (b) the Hall symbol and (c) the list of equivalent positions, and checks that *all three* are consistent!! Ralf Grosse-Kunstleve implemented the Hall symbols in cctbx so I presume that all Phenix programs understand them. Each Hall symbol corresponds to a list of general equivalent positions. However Hall symbols are not a perfect solution because (a) it is possible to have more than one Hall symbol for the same set of equivalent positions and (b) although the lists of possible Hall symbols are rather extensive, they do not cover all possible combinations of space groups and settings. For example the IUCr and Ralf's lists include the common non-standard setting P21/n (Hall: -P 2yn) for space group P21/c (Hall: -P 2ybc) but not the more rarely used non-standard setting B21/d of the same space group. In terms of equivalent positions this setting causes no problems, the SHELX notation for it is: LATT 6 SYMM 3/4+X, 1/2-Y, 1/4+Z So I have obstinately insisted for the last 40 years that the list of equivalent positions is the best way of specifying symmetry. It would have saved a great deal of confusion. I also do not accept the argument that a list of equivalent positions is error prone. Firstly they are almost always put there by a program, not a human being, and secondly SHELXL and other programs check them for internal consistency. Best wishes, George On 10/03/2014 07:58 PM, Ian Tickle 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). A*37*, 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 kay.diederi...@uni-konstanz.de mailto:kay.diederi...@uni-konstanz.de 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 abc _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
Re: [ccp4bb] Space group numbers
On Saturday, 04 October 2014 10:26:51 AM Kay Diederichs wrote: I do agree that in your use case it may be helpful to order abc as long as the symmetry is unknown. I also do understand that the H-M symbols allow to describe the different settings, but this is a level of complication that is not necessary to understand for todays's typical crystallographer, because fortunately e.g. the C121 setting is practically uniformly used (and chosen by POINTLESS, as far as I understand) to represent C2 crystals. I will not stick my nose into the main discussion here, but I will note that this part of it is incorrect. POINTLESS uses the IUCr convention to select either C2 or I2 depending an the beta angle. This caused me great confusion when I first encountered it, not least because a very slight variation in the refined beta angle can change the spacegroup in the output file. Ethan -- mail: Biomolecular Structure Center, K-428 Health Sciences Bldg MS 357742, University of Washington, Seattle 98195-7742
Re: [ccp4bb] Space group numbers
If you know the indexing that you want, from a user's point of view it is much easier to specify e.g. I want to choose spacegroup P6522 (with or without spaces), rather than Oh what's the number, I'll have to go and look it up. Phil On 2 Oct 2014, at 21:12, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: On Thu, 2 Oct 2014 16:00:30 +0100, Ian Tickle ianj...@gmail.com wrote: On 2 October 2014 13:51, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: I don't see any sticking to initial indexing as worthwhile to worry about, since in the first integration, P1 is often used anyway, and it is quite normal (and easy) to re-index after the intensities become available, during scaling. Re-indexing from P1 to the true spacegroup often changes the cell parameters and their order, and this is sufficiently easy and well-documented in the output. Ian, I'm not aware that I tried to impose re-indexing on anyone, which your reaction seems to imply. Quite to the contrary: re-indexing needs to be under the control of the user - and the user specifies cell parameters and space group number in XDS.INP. If I understand correctly, your use case is not the typical one encountered by novice crystallographers, and I'm quite sure you know very well how to deal with it. My whole point is about the default SETTING in POINTLESS which may lead to problems for XDS users, for space groups 17 and 18. To fix it, there is no need to re-invent the wheel, write new volumes of ITC, specify all space group operators, or specify space group symbols instead of numbers. best, Kay
Re: [ccp4bb] Space group numbers
Hi Kay On 2 October 2014 15:04, Kay Diederichs kay.diederi...@uni-konstanz.de 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 abc _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 ab but ITC doesn't specify that as a condition anywhere, it just says abc, not abc unless it's P2221 or P21212 when it's ab (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
Re: [ccp4bb] Space group numbers
Since this discussion doesn't want to end. I should point out (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). A*37*, 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. (b) Isn't it time to introduce the 'R 3' or 'H 3' or 'R 3 :H' issue again? (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). George On 10/03/2014 05:13 PM, Ian Tickle wrote: Hi Kay On 2 October 2014 15:04, Kay Diederichs kay.diederi...@uni-konstanz.de mailto:kay.diederi...@uni-konstanz.de 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 abc _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
Re: [ccp4bb] Space group numbers
(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). A*37*, 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 kay.diederi...@uni-konstanz.de 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 abc _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.
Re: [ccp4bb] Space group numbers
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 abc 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 ianj...@gmail.com 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). A*37*, 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 kay.diederi...@uni-konstanz.de 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 abc _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
Re: [ccp4bb] Space group numbers
On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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 abc) 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 abc . 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 simon.kols...@port.ac.uk 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
Re: [ccp4bb] Space group numbers
I second that! The default should be symmetry based... cells stretch and shrink, but symmetry is harder to change. (i.e. from crystal to crystal.) (I thought all CCP4 programs have supported this for ages.) On 02/10/2014 10:25, Kay Diederichs wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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 abc) 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 abc . 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 simon.kols...@port.ac.uk 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
Re: [ccp4bb] Space group numbers
The strange thing is that small molecule crystallographers do not suffer from this problem, because they don't use space group numbers! This is just as well, because instead of just 8 combinations of primitive orthorhombic space groups and settings, they have to consider 111 (if I have counted correctly). George On 10/02/2014 11:50 AM, Frank von Delft wrote: I second that! The default should be symmetry based... cells stretch and shrink, but symmetry is harder to change. (i.e. from crystal to crystal.) (I thought all CCP4 programs have supported this for ages.) On 02/10/2014 10:25, Kay Diederichs wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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 abc) 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 abc . 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 simon.kols...@port.ac.uk 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 -- 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
Re: [ccp4bb] Space group numbers
How does XDS decide on eg P 21 21 2 when say c b a? The initial indexing may decide that the cell fits a primitive orthorhombic system, but I presume that it will then have some convention, probably a b c, since the identification of screws can only be done after integration, and even then may be uncertain. If e.g. Pointless later decides that the a axis is a dyad, and the b c axes are 2(1) screws, then it can assign space group P 2 21 21 without permuting the indices. If XDS is assigning space group P 21 21 2 then it must have permuted the axes from the initial indexing. It seems to me more straightforward to stick to the initial indexing rather than having to reindex after you have decided the true space group: this was Ian Tickle's point and is also supposedly the official IUCr-approved convention. There are of course ambiguous cases e.g. a ~= b, but that is the same as the indexing ambiguities in e.g. P3, and that needs a reference dataset to resolve. There is no problem in solving a structure in e.g. P 2 21 21, and indeed I would always run MR in all 8 possible primitive orthorhombic space groups, very easy to do in Phaser Phil On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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 abc) 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 abc . 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 simon.kols...@port.ac.uk 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
Re: [ccp4bb] Space group numbers
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 have to define the setting if you refer to the standard symbol. I'm aware 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! Cheers -- Ian On 2 October 2014 10:25, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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 abc) 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 abc . 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 simon.kols...@port.ac.uk 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
Re: [ccp4bb] Space group numbers
With the successful introduction of racemic crystallization to macromolecular, a large number of possible space groups have been opened up to this audience. You can find examples in the PDB of space groups P -1 (i.e. P 1-bar), I -4 2 d, etc. On 10/02/14 06:51, George Sheldrick wrote: The strange thing is that small molecule crystallographers do not suffer from this problem, because they don't use space group numbers! This is just as well, because instead of just 8 combinations of primitive orthorhombic space groups and settings, they have to consider 111 (if I have counted correctly). George On 10/02/2014 11:50 AM, Frank von Delft wrote: I second that! The default should be symmetry based... cells stretch and shrink, but symmetry is harder to change. (i.e. from crystal to crystal.) (I thought all CCP4 programs have supported this for ages.) On 02/10/2014 10:25, Kay Diederichs wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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 abc) 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 abc . 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 simon.kols...@port.ac.uk 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 -- === All Things Serve the Beam === David J. Schuller modern man in a post-modern world MacCHESS, Cornell University schul...@cornell.edu
Re: [ccp4bb] Space group numbers
Yes, we ran into exactly that issue as well. Jūrgen .. Jürgen Bosch Johns Hopkins University Bloomberg School of Public Health Department of Biochemistry Molecular Biology Johns Hopkins Malaria Research Institute 615 North Wolfe Streetx-apple-data-detectors://4, W8708 Baltimore, MD 21205x-apple-data-detectors://5/0 Office: +1-410-614-4742tel:%2B1-410-614-4742 Lab: +1-410-614-4894tel:%2B1-410-614-4894 Fax: +1-410-955-2926tel:%2B1-410-955-2926 http://lupo.jhsph.eduhttp://lupo.jhsph.edu/ On Oct 2, 2014, at 05:38, Kay Diederichs kay.diederi...@uni-konstanz.demailto:kay.diederi...@uni-konstanz.de wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.ukmailto:p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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 abc) 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 abc . 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 simon.kols...@port.ac.ukmailto:simon.kols...@port.ac.uk 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
Re: [ccp4bb] Space group numbers
On Thu, 2 Oct 2014 11:38:08 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: How does XDS decide on eg P 21 21 2 when say c b a? The initial indexing may decide that the cell fits a primitive orthorhombic system, but I presume that it will then have some convention, probably a b c, since the identification of screws can only be done after integration, and even then may be uncertain. If e.g. Pointless later decides that the a axis is a dyad, and the b c axes are 2(1) screws, then it can assign space group P 2 21 21 without permuting the indices. If XDS is assigning space group P 21 21 2 then it must have permuted the axes from the initial indexing. It seems to me more straightforward to stick to the initial indexing rather than having to reindex after you have decided the true space group: this was Ian Tickle's point and is also supposedly the official IUCr-approved convention. XDS was written for users who read the table of H00 0K0 00L intensities and sigmas in CORRECT.LP (i.e. after integration), and know that the only pure two-fold rotation axis should be called c in space group 18, and the only two-fold screw axis should be called c in space group 17. This XDS user then has to choose the correct one out of the three possible ways to order the axes. So, XDS does not decide, the user decides. Nowadays many XDS users use POINTLESS, which is perfectly adequate, except for space groups 17 and 18 where the problem arises, unless the non-default SETTING SYMMETRY-BASED is chosen. I don't see any sticking to initial indexing as worthwhile to worry about, since in the first integration, P1 is often used anyway, and it is quite normal (and easy) to re-index after the intensities become available, during scaling. Re-indexing from P1 to the true spacegroup often changes the cell parameters and their order, and this is sufficiently easy and well-documented in the output. There are of course ambiguous cases e.g. a ~= b, but that is the same as the indexing ambiguities in e.g. P3, and that needs a reference dataset to resolve. There is no problem in solving a structure in e.g. P 2 21 21, and indeed I would always run MR in all 8 possible primitive orthorhombic space groups, very easy to do in Phaser this is true; running in all 8 possible primitive orthorhombic space groups is a fallback that should save the user, and I don't know why it didn't work out in that specific case. Still, personally I find it much cleaner to use the space group number and space group symbol from ITC together with the proper ordering of cell parameters. I rather like to think once about the proper ordering, than to artificially impose abc , and additionally having to specify which is the pure rotation (in 18) or the screw (in 17). And having to specify one out of 1017 / 2017 / 1018/ 2018/ 3018 is super-ugly because a) there is no way I could remember which is which, b) they are not in the ITC, c) XDS and maybe other programs do not understand them. best, Kay Phil On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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 abc) of cell parameters in XDS.INP. The easiest way, for XDS
Re: [ccp4bb] Space group numbers
On Thu, 2 Oct 2014 11:58:42 +0100, Ian Tickle ianj...@gmail.com 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 abc _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 kay.diederi...@uni-konstanz.de wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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 abc) 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
Re: [ccp4bb] Space group numbers
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 kay.diederi...@uni-konstanz.de wrote: On Thu, 2 Oct 2014 11:58:42 +0100, Ian Tickle ianj...@gmail.com 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 abc _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 kay.diederi...@uni-konstanz.de wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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 abc) 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
Re: [ccp4bb] Space group numbers
On 2 October 2014 13:51, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: I don't see any sticking to initial indexing as worthwhile to worry about, since in the first integration, P1 is often used anyway, and it is quite normal (and easy) to re-index after the intensities become available, during scaling. Re-indexing from P1 to the true spacegroup often changes the cell parameters and their order, and this is sufficiently easy and well-documented in the output. Far from it: re-indexing would be a huge problem for us and one we wish to avoid at all costs. We had a case where the systematic absences were ambiguous (not uncommon!) and for a long time it wasn't clear which of two SGs (P21212 or P212121) it was. So we simply kept our options open and assigned the SG in XDS as P222 in all cases. This of course meant that the cell was automatically assigned with abc. We have a LIMS system with an Oracle database which keeps track of all processing (including all the failed jobs!) and it was a fundamental design feature that all crystals of the same crystal form (i.e. same space group similar cell) were indexed the same way relative to a reference dataset (the REFINDEX program ensures this, by calculating the correlation coefficient of the intensities for all possible indexings). So crystals may be initially re-indexed from the processed SG (where for example 2 axes have similar lengths) to conform with the reference dataset (in P222), but then once they are in the database there's no way of storing a re-re-indexed dataset based on a different space group assignment without disruption of all previous processing. We collected datasets from about 50 crystals over a 6 month period and stored the data in the database as we went along before we had one which gave a Phaser solution (having tried all 8 SG possibilities of course), and that resolved the SG ambiguity without reference to systematic absences (it was P212121). But there was no way we were going to go back and re-index everything (for what purpose in any case?), since it would require deleting all the data from the database, re-running all the processing and losing all the logging tracing info of the original processing. However changing the space group in the MTZ header from P222 to P212121 without changing the cell is of course trivial. I don't see how symmetry trumps geometry can be a universal rule. How can it be if you're not even sure what the correct space group is? Also the IUCr convention in say monoclinic space groups requires that for a and c the two shortest non-coplanar axis lengths be chosen which is the same as saying that beta should be as close a possible to 90 (but by convention 90). This is an eminently sensible and practical convention! So in one case a C2 cell with beta = 132 transforms to I2 with beta = 93. It is important to do this because several programs analyse the anisotropy in directions around the reciprocal axes and if the axes are only 48 deg apart you could easily miss significant anisotropy in the directions perpendicular to the reciprocal axes (i.e. parallel to the real axes). So at least in this case it is essential that geometry trumps symmetry. this is true; running in all 8 possible primitive orthorhombic space groups is a fallback that should save the user, and I don't know why it didn't work out in that specific case. Still, personally I find it much cleaner to use the space group number and space group symbol from ITC together with the proper ordering of cell parameters. I rather like to think once about the proper ordering, than to artificially impose abc , and additionally having to specify which is the pure rotation (in 18) or the screw (in 17). And having to specify one out of 1017 / 2017 / 1018/ 2018/ 3018 is super-ugly because a) there is no way I could remember which is which, b) they are not in the ITC, c) XDS and maybe other programs do not understand them. I completely agree that the CCP4 SG numbers are super-ugly: they are only there for internal programmer use and should not be made visible to the user (I'm sure there are lots of other super-ugly things hiding inside software!). Please use the H-M symbols: a) they're trivial to remember, b) they are part of the official ITC convention, c) they're designed to be unique (even without embedded spaces!), and d) all programs that use the CCP4 symmetry library (also Global Phasing Phenix) recognise them. In any case XDS doesn't need to recognise any SG symbols with screw axes: they are totally irrelevant for integrating the images. If for example the user inputs the space group as P2122, P21212, P212121 my script will convert all screws to rotations so all of these become P222 for the purpose of running XDS. This of course doesn't affect XDS one iota, and I can change the MTZ header to the correct space group at my leisure (but definitely no re-indexing!). So I don't understand why the choice of P2122 vs
Re: [ccp4bb] Space group numbers
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 kay.diederi...@uni-konstanz.de wrote: On Thu, 2 Oct 2014 11:58:42 +0100, Ian Tickle ianj...@gmail.com 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 abc _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 kay.diederi...@uni-konstanz.de wrote: On Tue, 30 Sep 2014 13:29:02 +0100, Phil Evans p...@mrc-lmb.cam.ac.uk 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 abc 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 abc . 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 abc . 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,
Re: [ccp4bb] Space group numbers
How can it be if you're not even sure what the correct space group is? Ambiguities may arise in the presence of pseudosymmetry and/or packing disorders. In some cases, you can determine crystal structure from the same data in different space groups that do not have subgroup/supergroup relationship. One of the space groups may produce better results, something that can be determined quite late into the process. Similar situation may arise then merging data from multiple nearly isomorphous crystals that individually may be better describes by alternative space group symmetries. Zbyszek Otwinowski On 2 October 2014 13:51, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: I don't see any sticking to initial indexing as worthwhile to worry about, since in the first integration, P1 is often used anyway, and it is quite normal (and easy) to re-index after the intensities become available, during scaling. Re-indexing from P1 to the true spacegroup often changes the cell parameters and their order, and this is sufficiently easy and well-documented in the output. Far from it: re-indexing would be a huge problem for us and one we wish to avoid at all costs. We had a case where the systematic absences were ambiguous (not uncommon!) and for a long time it wasn't clear which of two SGs (P21212 or P212121) it was. So we simply kept our options open and assigned the SG in XDS as P222 in all cases. This of course meant that the cell was automatically assigned with abc. We have a LIMS system with an Oracle database which keeps track of all processing (including all the failed jobs!) and it was a fundamental design feature that all crystals of the same crystal form (i.e. same space group similar cell) were indexed the same way relative to a reference dataset (the REFINDEX program ensures this, by calculating the correlation coefficient of the intensities for all possible indexings). So crystals may be initially re-indexed from the processed SG (where for example 2 axes have similar lengths) to conform with the reference dataset (in P222), but then once they are in the database there's no way of storing a re-re-indexed dataset based on a different space group assignment without disruption of all previous processing. We collected datasets from about 50 crystals over a 6 month period and stored the data in the database as we went along before we had one which gave a Phaser solution (having tried all 8 SG possibilities of course), and that resolved the SG ambiguity without reference to systematic absences (it was P212121). But there was no way we were going to go back and re-index everything (for what purpose in any case?), since it would require deleting all the data from the database, re-running all the processing and losing all the logging tracing info of the original processing. However changing the space group in the MTZ header from P222 to P212121 without changing the cell is of course trivial. I don't see how symmetry trumps geometry can be a universal rule. How can it be if you're not even sure what the correct space group is? Also the IUCr convention in say monoclinic space groups requires that for a and c the two shortest non-coplanar axis lengths be chosen which is the same as saying that beta should be as close a possible to 90 (but by convention 90). This is an eminently sensible and practical convention! So in one case a C2 cell with beta = 132 transforms to I2 with beta = 93. It is important to do this because several programs analyse the anisotropy in directions around the reciprocal axes and if the axes are only 48 deg apart you could easily miss significant anisotropy in the directions perpendicular to the reciprocal axes (i.e. parallel to the real axes). So at least in this case it is essential that geometry trumps symmetry. this is true; running in all 8 possible primitive orthorhombic space groups is a fallback that should save the user, and I don't know why it didn't work out in that specific case. Still, personally I find it much cleaner to use the space group number and space group symbol from ITC together with the proper ordering of cell parameters. I rather like to think once about the proper ordering, than to artificially impose abc , and additionally having to specify which is the pure rotation (in 18) or the screw (in 17). And having to specify one out of 1017 / 2017 / 1018/ 2018/ 3018 is super-ugly because a) there is no way I could remember which is which, b) they are not in the ITC, c) XDS and maybe other programs do not understand them. I completely agree that the CCP4 SG numbers are super-ugly: they are only there for internal programmer use and should not be made visible to the user (I'm sure there are lots of other super-ugly things hiding inside software!). Please use the H-M symbols: a) they're trivial to remember, b) they are part of the official ITC convention, c) they're designed
Re: [ccp4bb] Space group numbers
On Thu, 2 Oct 2014 16:00:30 +0100, Ian Tickle ianj...@gmail.com wrote: On 2 October 2014 13:51, Kay Diederichs kay.diederi...@uni-konstanz.de wrote: I don't see any sticking to initial indexing as worthwhile to worry about, since in the first integration, P1 is often used anyway, and it is quite normal (and easy) to re-index after the intensities become available, during scaling. Re-indexing from P1 to the true spacegroup often changes the cell parameters and their order, and this is sufficiently easy and well-documented in the output. Ian, I'm not aware that I tried to impose re-indexing on anyone, which your reaction seems to imply. Quite to the contrary: re-indexing needs to be under the control of the user - and the user specifies cell parameters and space group number in XDS.INP. If I understand correctly, your use case is not the typical one encountered by novice crystallographers, and I'm quite sure you know very well how to deal with it. My whole point is about the default SETTING in POINTLESS which may lead to problems for XDS users, for space groups 17 and 18. To fix it, there is no need to re-invent the wheel, write new volumes of ITC, specify all space group operators, or specify space group symbols instead of numbers. best, Kay Far from it: re-indexing would be a huge problem for us and one we wish to avoid at all costs. We had a case where the systematic absences were ambiguous (not uncommon!) and for a long time it wasn't clear which of two SGs (P21212 or P212121) it was. So we simply kept our options open and assigned the SG in XDS as P222 in all cases. This of course meant that the cell was automatically assigned with abc. We have a LIMS system with an Oracle database which keeps track of all processing (including all the failed jobs!) and it was a fundamental design feature that all crystals of the same crystal form (i.e. same space group similar cell) were indexed the same way relative to a reference dataset (the REFINDEX program ensures this, by calculating the correlation coefficient of the intensities for all possible indexings). So crystals may be initially re-indexed from the processed SG (where for example 2 axes have similar lengths) to conform with the reference dataset (in P222), but then once they are in the database there's no way of storing a re-re-indexed dataset based on a different space group assignment without disruption of all previous processing. We collected datasets from about 50 crystals over a 6 month period and stored the data in the database as we went along before we had one which gave a Phaser solution (having tried all 8 SG possibilities of course), and that resolved the SG ambiguity without reference to systematic absences (it was P212121). But there was no way we were going to go back and re-index everything (for what purpose in any case?), since it would require deleting all the data from the database, re-running all the processing and losing all the logging tracing info of the original processing. However changing the space group in the MTZ header from P222 to P212121 without changing the cell is of course trivial. I don't see how symmetry trumps geometry can be a universal rule. How can it be if you're not even sure what the correct space group is? Also the IUCr convention in say monoclinic space groups requires that for a and c the two shortest non-coplanar axis lengths be chosen which is the same as saying that beta should be as close a possible to 90 (but by convention 90). This is an eminently sensible and practical convention! So in one case a C2 cell with beta = 132 transforms to I2 with beta = 93. It is important to do this because several programs analyse the anisotropy in directions around the reciprocal axes and if the axes are only 48 deg apart you could easily miss significant anisotropy in the directions perpendicular to the reciprocal axes (i.e. parallel to the real axes). So at least in this case it is essential that geometry trumps symmetry. this is true; running in all 8 possible primitive orthorhombic space groups is a fallback that should save the user, and I don't know why it didn't work out in that specific case. Still, personally I find it much cleaner to use the space group number and space group symbol from ITC together with the proper ordering of cell parameters. I rather like to think once about the proper ordering, than to artificially impose abc , and additionally having to specify which is the pure rotation (in 18) or the screw (in 17). And having to specify one out of 1017 / 2017 / 1018/ 2018/ 3018 is super-ugly because a) there is no way I could remember which is which, b) they are not in the ITC, c) XDS and maybe other programs do not understand them. I completely agree that the CCP4 SG numbers are super-ugly: they are only there for internal programmer use and should not be made visible to the user (I'm sure there are lots of other super-ugly things hiding inside
[ccp4bb] Space group numbers
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
Re: [ccp4bb] Space group numbers
Look at $CLIBD/syminfo.lib All listed by number as well as other flags.. Eleanor On 30 September 2014 13:17, Philip Kiser p...@case.edu wrote: From XDS: ** LATTICE SYMMETRY IMPLICATED BY SPACE GROUP SYMMETRY ** BRAVAIS-POSSIBLE SPACE-GROUPS FOR PROTEIN CRYSTALS TYPE [SPACE GROUP NUMBER,SYMBOL] aP [1,P1] mP [3,P2] [4,P2(1)] mC,mI[5,C2] oP [16,P222] [17,P222(1)] [18,P2(1)2(1)2] [19,P2(1)2(1)2(1)] oC [21,C222] [20,C222(1)] oF [22,F222] oI [23,I222] [24,I2(1)2(1)2(1)] tP [75,P4] [76,P4(1)] [77,P4(2)] [78,P4(3)] [89,P422] [90,P42(1)2] [91,P4(1)22] [92,P4(1)2(1)2] [93,P4(2)22] [94,P4(2)2(1)2] [95,P4(3)22] [96,P4(3)2(1)2] tI [79,I4] [80,I4(1)] [97,I422] [98,I4(1)22] hP [143,P3] [144,P3(1)] [145,P3(2)] [149,P312] [150,P321] [151,P3(1)12] [152,P3(1)21] [153,P3(2)12] [154,P3(2)21] [168,P6] [169,P6(1)] [170,P6(5)] [171,P6(2)] [172,P6(4)] [173,P6(3)] [177,P622] [178,P6(1)22] [179,P6(5)22] [180,P6(2)22] [181,P6(4)22] [182,P6(3)22] hR [146,R3] [155,R32] cP [195,P23] [198,P2(1)3] [207,P432] [208,P4(2)32] [212,P4(3)32] [213,P4(1)32] cF [196,F23] [209,F432] [210,F4(1)32] cI [197,I23] [199,I2(1)3] [211,I432] [214,I4(1)32] Probably shouldn't take too long to extract the SG numbers to a list. Philip On Tue, Sep 30, 2014 at 8:07 AM, Simon Kolstoe simon.kols...@port.ac.uk 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
Re: [ccp4bb] Space group numbers
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 abc 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 simon.kols...@port.ac.uk 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
Re: [ccp4bb] Space group numbers
Hi all, Thanks for your help. CORRECT.LP includes precisely the information I was after. Also Ian Tickle’s article on http://www.ccp4.ac.uk/html/alternate_origins.html is very helpful. Simon
