JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for CCP4BB Archives


CCP4BB Archives

CCP4BB Archives


CCP4BB@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

CCP4BB Home

CCP4BB Home

CCP4BB  October 2014

CCP4BB October 2014

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Space group numbers

From:

Kay Diederichs <[log in to unmask]>

Reply-To:

Kay Diederichs <[log in to unmask]>

Date:

Sat, 4 Oct 2014 10:26:51 +0200

Content-Type:

multipart/signed

Parts/Attachments:

Parts/Attachments

text/plain (151 lines) , smime.p7s (151 lines)

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 a<b<c 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 a<b<c 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 <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
>
> Once again, citing from ITC Vol A Table 9.3.2 (p. 747 in my 1995
> edition) , these "conventions refer to the cell obtained by the
> transformations from Table 9.3.1. They have been chosen for
> convenience in this table". To me, this indicates that a<b<c _could_
> be obtained _if_ one were to transform. But the question is: why
> would one want to transform? I don't see "sticking to the original
> indexing" as a convincing convenience.
>
>
> I'm sorry, unfortunately my edition of ITC-A (5th Ed., 2002) is later
> than yours (4th Ed.) and I have been unable to get hold of a copy of the
> edition that you refer to. In my edition the table equivalent to your
> 9.3.2 seems to be 9.3.4.1 on p.758 and there doesn't seem to be a table
> equivalent to your 9.3.1 (the only other table in that section is
> 9.3.5.1 but that doesn't seem to be relevant). Also I am unable to
> match up the text that you quote with what I see in my edition: it seems
> to be completely different. So it's very difficult to comment.
> According to the Foreword "The present 5th Edition is much more
> extensively revised than any of its predecessors ..." so I can only
> assume that the text that you quote was considered unclear and was
> removed. But I agree that if one is concerned with a specific structure
> without reference to any other structure, why would one want to
> transform anything? It makes no sense. The conventional setting is
> selected according to table 9.3.4.1, end of story.
>
>
> My copy of ITC Vol A says (p 41) about Table 3.2: "the 'standard'
> space group symbols ... are printed in bold face". The Table has "P
> 21 21 2" (18) and "P 2 2 21" (17) in bold face. There is no
> ambiguity here.
>
>
> Again I'm sorry but I don't see that text in my edition (p.41 is just a
> list of references for Chap. 2) and I can't find the corresponding
> section in my Edition. However I do agree that the standard symbol for
> each space group is printed in bold face in the top-left corner of each
> double-spread page dealing with that space group (also in smaller type
> in the top-right corner). Perfectly true observation I agree but how is
> it relevant? The 230 standard symbols are the names of the 230
> equivalence classes defined on the complete set of possible alternate
> settings for the equivalence relations consisting of the possible
> rotations and/or translations relating those alternate settings. Since
> they only serve as labels one could equally well have chosen the
> ordinals 1 through 230 (which are actually given equal prominence to the
> names).
>
> The important point is that the standard symbol is only the _name_ of
> the equivalence class and that this is not sufficient for dealing with
> crystal structures and calculating structure factors etc.: one must
> specify which element of that class, i.e. from the subset of possible
> unique _settings_ that are members of that class, to use. For example
> in the 5th Ed. the 10 possible settings for standard symbol C2 are
> shown, with the full H-M symbols C121, A121, I121, A112, B112 etc. So
> e.g. A121 is one of the allowed conventional settings in the equivalence
> class C2. Notice that the standard symbol C2 is _not_ a full H-M
> symbol: it doesn't need to be, since it's only a name and it doesn't
> need to carry any information. Its only requirement is that it's unique
> among the 230 equivalence classes. Similarly the page for standard
> symbol P2221 shows the possible settings (at least in my Ed.) P2221,
> P2212 and P2122. In this case the standard symbol happens to be the
> same as one of the full H-M symbols of the alternate settings but that's
> not a requirement, any unique name would have done equally well. Also
> in the setting P2221 there obviously remains an ambiguity concerning the
> assignment of the a and b axes. How is that resolved? You will
> probably say a<b but ITC doesn't specify that as a condition anywhere,
> it just says "a<b<c", not "a<b<c unless it's P2221 or P21212 when it's
> a<b" (the first condition doesn't require exceptions).
>
> Have you considered the fact that not all possible alternate settings
> are listed for all space groups? For example no trigonal, tetragonal or
> hexagonal settings have a or b unique (you can find many other examples
> in the monoclinic & orthorhombic systems, e.g. there are no B settings
> in orthorhombic). Why is that? What's so special about the settings
> that are listed that doesn't apply to all the ones not listed? You can
> be sure it's by very careful design since printing space was at a
> premium when the tables were first published (I spent my first post doc.
> at the Laboratorium voor Struktuurchemie at the Rijksuniversiteit
> Groningen at the same time Dirk Fokkema was there: he wrote the software
> for the computer-driven typesetting of the main Vol. A table of space
> groups for his Ph.D. thesis; we had a number of discussions about space
> groups and I can assure you that the table was very carefully
> designed!). The answer is that the settings listed are strictly those
> that satisfy the requirements of the rules on conventional cells in
> table 9.3.4.1, no more, no less. The appropriate setting is selected
> from the members of the equivalence class of the space group in question
> according to those rules.
>
>
> Switching the default in POINTLESS from "SETTING CELL-BASED" to
> "SETTING SYMMETRY-BASED" would make me happy, but more importantly,
> would avoid a lot of problems.
>
>
> Maybe the answer is to fix the problem with pointless that you
> highlighted originally, i.e. it's apparently reporting the wrong space
> group in the log file! Actually extracting stuff from log files is a
> very bad idea: log files are not guaranteed to remain the same across
> different versions of the program! I learnt that the hard way! Doesn't
> pointless output an XML file, or you could just read the MTZ file
> header. That's what I do, it's much safer.
>
> Cheers
>
> -- Ian


Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager