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:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CCP4BB Home

CCP4BB Home

CCP4BB  January 2016

CCP4BB January 2016

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Spacegroups, screw axes and ordering

From:

Phil Evans <[log in to unmask]>

Reply-To:

Phil Evans <[log in to unmask]>

Date:

Sun, 31 Jan 2016 22:44:41 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (137 lines)

Back to the original question

I still fail to see the objection to space groups such as P 21 2 21 - these are consistent with international conventions and cause no real confusion

We can consider a number of common scenarios following indexing of the dfifraction pattern and integration

1. Simple case: the indexing is correct, the Laue group is obvious and the axial systematic absences clearly indicate the space group. No problem, though you may still wish to test all the space groups in the Laue group. This may of course indicate that the space group is e.g. P 21 2 21, see point 3

2. The indexing is incorrect, but examination of the rotational symmetry (e.g. in Pointless) indicates the Laue group. Usually this gives a clear reindexing, and maybe the space group.

3. The Laue group is clear, but systematic absences are missing or unclear on e.g. one axis, often the case in primitive orthorhombic space groups. Pointless marks the data as “space group” P222 as a Laue group. This is then resolved by testing structure solutions in all possible space groups within the Laue group, e.g. the eight possible P2x2x2x primitive orthorhombics, which is easy in molecular replacement with Phaser, and is also necessary  for experimental phasing  (though it should be easier to do automatically). If the best solution comes up in say P21 2 21, that can go straight into refinement without further changes. If you insist on changing the space group to P 21 21 2, that means reindexing the data and the solution coordinates, which is likely to cause endless confusion, and is entirely unnecessary.

4. There are indexing ambiguities, or the true space group is known from earlier crystals. In these cases it is sensible to give a reference data set to specify the space group and to give consistent indexing. This has nothing to do with whether the space group is e.g. P 21 2 21 or P 21 21 2.

 In the new ccp4i2 GUI, a warning message such as the following is printed if alternative indexing is possible and no reference data are given

	NOTE: the final selected symmetry has alternative indexing schemes, but no reference data has been given
	Possible alternative indexing operators: [h,k,l], [-k,h,l]
	If you already have a matching dataset, you should choose it as a reference set to get consistent indexing

Why is this a problem?

Phil


> On 30 Jan 2016, at 21:10, James Holton <[log in to unmask]> wrote:
> 
> 
> One very good reason not to drop everything to P1 is because of Rfree.  
> 
> If you drop to P1, pick a "random" Rfree set, and then apply n-fold NCS (aka the crystallographic symmetry), then every reflection in the "free" set has at least one "NCS-mate" in the working set.  Rwork and Rfree would then always be close together (depending on the NCS weight), and by increasing the overall X-ray weight you could get any Rfree you want, even if the structure is totally wrong.  
> 
> It's surprising how many people have made the mistake of swapping CS for NCS.  Just search the PDB for structures in P21 with beta angle ~ 90.  A few of them are really P21, but not many.
> 
> Yes, you could make your free-set picking algorithm smarter, but that requires knowing what the symmetry is!  "thin shells" are not always enough.  Especially if you process in P1 and cell edges or angles that should be identical are allowed to drift. Where you can really get yourself into trouble is with pseudo-symmetry, such as P222 with an NCS threefold along the diagonal.  Or is that P23?  I myself only recently realized that C222 is actually a subset of             P622.  Yes, you can solve any structure that is really P622 in C222 and everything will work.  Except Rfree with NCS, of course.
> 
> This has drifted a bit from the OP question, but perhaps the common thread here is that there really is a need for better tools when it comes to choice of symmetry.  If you change your space group from H3 to R3, why is it not the default to update the unit cell and re-index the hkls as well?  Same for P312 to C2, which is really just dropping one symmetry operator (although it is not obvious from looking at the tables).  
> 
> I think the reason is that there will always be two camps when it comes to automation: 1) people who want the sensible thing they always do manually to be automatic, and 2) people who don't want default behaviors to change and break their stuff, producing a lot of unintended consequences when all you want to do is something simple.  When writing automation software (like xia2) it is difficult to discern how much the user "cares" about a given parameter.  Did they enter "P222" because they don't know what the space group is?  Or did they enter it because they actually think they are in the rarest space group of them all?  The solution I arrived upon in Elves was to add the extension "-ish" to the space group name whenever it is not set in stone.  Doesn't work in the mtz header, of course, but maybe it should?  A flag for "soft symmetry"?
> 
> In response to the OP, I still prefer using space groups that have numbers less than 1000.  This is because there are programs (like XDS) that only use space group numbers.  Space group number "18" is P21212 in the International Tables, not P22121 nor P21221. That, and I have never seen violation of the a < b < c rule break anything.  P22121, however, does break things (and the list changes over time).  R3 is even worse.
> 
> At the end of the day, I think it would be great if refinement programs (and their users) could be a bit smarter when it comes to symmetry-allowed transformations. Imagine a tool that would allow you to say: "darn it, I want to switch from P22121 to P21212", and it would change your pdb and mtz to do that.  If it were that easy, we wouldn't be having this discussion.  Moreover, how about: "hey, I want to switch my refinement from P6122 to C2", and it would expand out your PDB and re-scale your raw data.  I think such a tool would be a popular one.  Especially when you're trying to figure out twinning.
> 
> -James Holton
> MAD Scientist
> 
> On Fri, Jan 29, 2016 at 6:10 AM, Quyen Hoang <[log in to unmask]> wrote:
> Given enough data and modern computing powers, why don’t we just use P1?
> 
> Quyen
> 
> 
>> On Jan 29, 2016, at 8:45 AM, George Sheldrick <[log in to unmask]> wrote:
>> 
>> The collection and scaling requires the Laue group but not the space group. For small molecule structure determination, many more space groups have to be considered and the choice may be ambiguous (like I222 and I212121) or difficult, so my current small molecule structure solution program SHELXT only uses the input space group to deduce the Laue group. After solving the structure with the data expanded to P1 it uses the phases to determine the space group and origin shift. In practice this is much more reliable than using systematic absences. This was not my idea (see papers by Giacovazzo and Palatinus), I just wrote a little program to implement it. How the user has chosen a, b and c is irrelevant, the program outputs the solution in the conventional setting for the space group in question (as the correct enantiomorph based on the Friedel differences where appropriate). It also finds the most compact arrangement of atoms and centers it is the unit-cell.
>> 
>> Whether this was worth the effort is debatable. SHELXT has been freely available for the last couple of years, but the open access paper that explains how it works (Acta A71 (2015) 3-8) is rarely cited.
>> 
>> George
>> 
>> 
>> On 01/29/2016 01:06 PM, Ian Tickle wrote:
>>> 
>>> Hi Kay
>>> 
>>> You are seriously misrepresenting how this works in practice.  Isomorphism always takes precedence over convention: convention is not an absolute requirement!  Convention is the _default_ in the absence of all other criteria (that's why we have conventions!). Only the _first_ crystal in an isomorphous series would be indexed by convention, the others would be indexed using that as a reference (i.e. based on the intensity correlation, _not_ the unit cell or the assumed space group which may not be reliable, using REFINDEX, which is what we have always used, or POINTLESS) - very simple!  At Astex we have be doing this for our large fragment screens for 15 years with no problem.
>>> 
>>> In any case we find that assignment of screw axes by axial reflexions is very unreliable (we have been stung on several occasions!) and we always postpone choice of space group until _after_ the experimental phasing or MR step, or even after the structure refinement step, i.e. doing MR and/or refinement in _all_ 8 possible space groups.  So space groups #16, 17, 18 & 19 would always be initally assigned as space group #16 (P222): that's what XDS does anyway, so no change there!  I would _always_ recommend that procedure over relying on the axial reflexions for space-group assigment.  For some datasets many of the reflexions on one of the axes were not even measured! (i.e. where the crystal happens to be aligned along an axis and only a single scan is done).
>>> 
>>> Contrary to what you are asserting, the convention you propose has been the source of great confusion & muddle in the past, whereas the internationally-agreed one is very clear and has been largely free from confusion (obviously because it was very carefully designed to be that way).  What happened on a number of occasions in the past (and quite possibly still happens in some labs) was that the space group was initally assigned as P222 according to the clear procedure described above, with the conventional cell correctly assigned as a <= b <= c.  What should happen then is that once the correct space group has been decided, the space group in the header is changed to that - simple, end of story.  However some people think they have to re-index to the 'standard setting' for SGs 17 & 18 (note that the standard setting has nothing to do with the conventional cell defined in ITC).  So they end up with files indexed differently - a recipe for disaster, since they can easily forget to also transform the co-ordinate file from the MR step, or they do manage to transform it but then mix up the files, thus R-value = random!  I have had to sort out peoples' mess on a number of occasions which is why I specified the above idiot-proof procedure when we designed the Astex fragment-screening pipeline back in 2000.
>>> 
>>> See these papers by Alan Mighell at NIST (one of the original authors of the conventional cell tables in ITC) for why we need conventions.
>>> 
>>> http://nvlpubs.nist.gov/nistpubs/jres/106/6/j66mig.pdf
>>> http://nvlpubs.nist.gov/nistpubs/jres/107/4/j74mig.pdf
>>> 
>>> The most important feature of an international convention is that it is documented in detail, otherwise how on earth will anyone know how to apply the                                 convention?  The document for the IUCr conventional cells is the ITC, based in part on the proposals in the above papers.  I'm not aware of any documentation (for all 230 space groups BTW!) for the convention that you are proposing.  I just don't understand why after we've all agreed on a convention (or at least our national representatives on the relevant IUCr committees on conventions have on our behalf), why you then want to go and do something completely different?
>>> 
>>> Cheers
>>> 
>>> -- Ian
>>> 
>>> 
>>> 
>>> On 29 January 2016 at 09:30, Kay Diederichs <[log in to unmask]> wrote:
>>> Good morning Graeme,
>>> 
>>> as may be obvious from earlier conversations about this, I have a rather strong opinion about this: even in 2016,
>>> - the a < b < c ordering has no scientific advantage in any way; it may appear more aesthetic to some
>>> - the ordering has a clear disadvantage if two cell edges are about the same length, because then, for different measurements, you may end up with different symmetries. This would be even worse if all three a,b,c are approximately the same. What a nightmare e.g. in serial crystallography!
>>> 
>>> Crystallography is difficult enough. Our choices should be such that we make it easier for novices to understand it, and to avoid errors. Failure to find (or think about) the proper re-indexing is one of the most often occurring problems.
>>> 
>>> best,
>>> 
>>> Kay
>>> 
>>> 
>>> 
>>> On Fri, 29 Jan 2016 09:13:16 +0000, Graeme Winter <[log in to unmask]> wrote:
>>> 
>>> >Good morning all,
>>> >
>>> >It is with some trepidation I raise the following question: does anyone still care about reindexing orthorhombic lattices so that the unique axis is C? I.e. P21221 => P21212
>>> >
>>> >Back in the day certain programs would express unhappiness if you fed them P21 2 21 (say) data - I am certain that this problem has gone away. Is there any reason in 2016 that (say) xia2 should write out symmetry based not cell based data? I am leaning towards indexing these so that a < b < c and then the screw axes are whatever they are.
>>> >
>>> >How do people feel about this?
>>> >
>>> >Thanks & best wishes Graeme
>>> >
>>> >--
>>> >This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
>>> >Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
>>> >Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
>>> >Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>>> 
>> 
>> 
>> -- 
>> 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
>> 
>> 
>> 
> 
> 

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