 |
 |
Or keep data unmerged, or as…images? Space group would then become just another refineable restraint/constraint. I guess it already is that, but is refined separately from “refinement.” JPK From: CCP4 bulletin board [mailto:[log in to unmask]] On Behalf Of Quyen Hoang Sent: Friday, January 29, 2016 9:11 AM To: [log in to unmask] Subject: Re: [ccp4bb] Spacegroups, screw axes and ordering 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]<mailto:[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]<mailto:[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]<mailto:[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