> -----Original Message----- > From: Winn, MD (Martyn) [mailto:martyn.w...@stfc.ac.uk] > Sent: 12 June 2009 23:31 > To: Ian Tickle > Cc: CCP4BB@JISCMAIL.AC.UK > Subject: RE: [ccp4bb] mtz2various is broken [ was: Another pointless > question ] > > > I didn't mean to commit to a particular solution. That wouldn't be > wise on a Friday night with jet lag ;) > > As an internal call in mtz2various, it should use symops ... but I need > to check that this works.
But it's not specifically an mtz2various problem surely (that's why I got interested!), it affects any program using MSYMLBx (which means most of them, including all of our internal ones). As you're clearly already well long the path of defining space groups via names and/or symm ops, the obvious fix it seems to me is to make the SG name take precedence inside MSYMLBn when both are valid. This is the behaviour that the documentation ($CDOC/symlib.doc) currently describes! I can't imagine circumstances where this wouldn't work since in the majority of cases (i.e. except files from Clipper) there will be no conflict between SG name & number anyway. The obvious (and possibly safer and even desirable) alternative is to fix Clipper so that it's backwards-compatible with symlib, i.e. so it doesn't change the SG number when transferring the header from i/p to o/p MTZ file. It's hard to see that Clipper has any internal use anyway for a non-unique SG number, except for export to CIF, log files etc. In fact there seems no reason why you can't take the 'belt and braces' approach and implement both fixes: this will reduce the number of problems arising from transfer of MTZ files between sites that have not yet implemented the patches. > Spacegroup number vs name is an issue for the user interface (graphical > or otherwise). We always try to support as many "standards" as possible, > but there will always be ambiguities. 'User' here of course needn't be a human user, for us it will normally an automation script. A while back I came to the conclusion that the new SG names with embedded spaces (& quoted or unquoted) were causing so many problems with our scripts that I decided to change them to use the unique SG numbers instead. For example if the SG name was used as a shell script argument it had to be quoted, but the script removes the quotes, so then if this script called another script you needed multiple levels of quotes, then you had to remember to check if the name was already quoted and put the quotes back on if it wasn't - it just got very messy! If I had realised at the time that the spaces weren't actually necessary, and all I had to do was remove them I would have saved myself a lot of bother! AFAICS SG names with embedded spaces are only needed for export (e.g. to PDB & CIF) and/or for human readability in log files, though personally I've never had any trouble reading, say, 'P41212' as opposed to 'P 41 21 2'. I don't see the need for them internally (in fact I see that Clipper strips embedded spaces from its SG names when writing an MTZ header). Enough said, I just saw Eleanor's post, she has covered my main points - I seem to be preaching to the converted! Cheers -- Ian > > m > > -----Original Message----- > From: Ian Tickle [mailto:i.tic...@astex-therapeutics.com] > Sent: Fri 6/12/2009 10:45 PM > To: Winn, MD (Martyn) > Cc: CCP4BB@JISCMAIL.AC.UK; Kevin Cowtan; Phil Evans; Ethan Merritt; > Eleanor Dodson > Subject: RE: [ccp4bb] mtz2various is broken [ was: Another pointless > question ] > > > Hi Martyn > > Since seeing Ethan's last posting I guessed immediately, following on > from what Kevin had said earlier, that the program in Ethan's sequence > which made the change from SG #4005 to #5 in the MTZ header (and my > tests confirm this) is ctruncate; this behaviour presumably is a feature > of the Clipper library, so I guess is common to all programs using > Clipper (though pointless appears to be an exception - presumably > because it specifically creates the 4005 code rather than simply > transferring it from input to output). All the other programs in his > sequence copy the SG #4005 unchanged. > > So essentially the problem is an incompatibility between the old > (c)symlib and the Clipper library; the former still uses the old > conventions that 1) the SG number uniquely identifies alternative > settings corresponding to a given standard setting, and 2) the SG number > takes precedence over the SG name and/or symm ops to determine the space > group, whereas the latter doesn't use unique numbers to identify > alternative settings, and assumes the reverse precedence. > > You suggest changing MSYMLB3 to fix this, i.e. essentially changing it > to conform to the symlib documentation (!), so that the SG name takes > precedence over the number - I agree this ought to work. The only issue > I see is that many programs (e.g. see several examples of this usage in > SFALL documentation) allow user input of either the SG name or number, > e.g. in SFALL, PDBSET etc: > > SYMM I2 > and > SYMM 4005 > > are equivalent. If we are going to move to the new Clipper-style > convention I wonder how this would be handled, if the SG numbers no > longer uniquely identify the setting. I guess we would lose this rather > useful (IMO at least) feature! I assume you would at least continue to > allow use of CCP4-style SG numbers via MSYMLB3 - all our internal > scripts rely on this feature. > > Cheers > > -- Ian > > > -----Original Message----- > > From: owner-ccp...@jiscmail.ac.uk [mailto:owner-ccp...@jiscmail.ac.uk] > On > > Behalf Of Martyn Winn > > Sent: 12 June 2009 20:46 > > To: Ethan Merritt > > Cc: CCP4BB@JISCMAIL.AC.UK > > Subject: Re: [ccp4bb] mtz2various is broken [ was: Another pointless > > question ] > > > > Apologies, have been away. I hope I have extracted the relevant points > > from this thread. > > > > For the record, the CCP4 library also uses the symops to determine the > > spacegroup, when it can. Hence the observation below that mtzdmp and > > refmac find the right spacegroup. > > > > However there are plenty of cases where the symops are not available, > > PDB files with CRYST1 card only, user keywords, etc. And there is > plenty > > of independently developed application code which may not follow the > > library (bearing in mind that we are an anarcho-syndicalist commune > etc > > etc). > > > > Ian is right that the surest way of checking the MTZ file is to open > in > > a text editor. You can also edit the SYMINF line this way, though this > > is probably classed as advanced ccp4 usage... So in my tests > > > > SYMINF 4 2 I 4005 'I 1 2 1' PG2 > > > > works fine, while > > > > SYMINF 4 2 I 5 'I 1 2 1' PG2 > > > > shows the problem. And yes, the problem is then MSYMLB3 using the 5 > > rather than the spacegroup name or the operators. We should be able to > > fix that. > > > > 4005 is for internal usage, converting to 5 on export from the suite. > > Probably the generating program should have used 4005. > > > > Cheers > > Martyn > > > > > My mtz file contains > > > CELL 148.6099 98.3798 251.9687 90.0000 90.3258 90.0000 > > > SORT 1 2 3 0 0 > > > SYMINF 4 2 I 5 'I121' PG2 > > > SYMM X, Y, Z > > > SYMM -X, Y, -Z > > > SYMM X+1/2, Y+1/2, Z+1/2 > > > SYMM -X+1/2, Y+1/2, -Z+1/2 > > > RESO 0.0000607290094194 0.1371708661317825 > > > > > > So there is a difference, but not the expected one. > > > My mtz file has exactly the info that should go into the cif > headers, > > > including the space group number of the standard setting: 5. > > > But mtzdmp and refmac, etc, do manage to find and report the > spacegroup > > > as 4005 from this same file. > > > Could there be two conflicting spacegroup numbers stored in the > header? > > > > > > For what it's worth. I see the same behavior on files created by > > > pointless (re-indexed from C2), files created directly by > > > mosflm/scala/truncate, and files merged by CAD. > > > > > > Ethan > > > > > > -- > > > *********************************************************************** > > * > * > > * Dr. Martyn Winn > * > > * > * > > * STFC Daresbury Laboratory, Daresbury, Warrington, WA4 4AD, U.K. > * > > * Tel: +44 1925 603455 E-mail: martyn.w...@stfc.ac.uk > * > > * Fax: +44 1925 603825 Skype name: martyn.winn > * > > * URL: http://www.ccp4.ac.uk/martyn/ > * > > > *********************************************************************** > > > > Disclaimer > This communication is confidential and may contain privileged information > intended solely for the named addressee(s). It may not be used or > disclosed except for the purpose for which it has been sent. If you are > not the intended recipient you must not review, use, disclose, copy, > distribute or take any action in reliance upon it. If you have received > this communication in error, please notify Astex Therapeutics Ltd by > emailing i.tic...@astex-therapeutics.com and destroy all copies of the > message and any attached documents. > Astex Therapeutics Ltd monitors, controls and protects all its messaging > traffic in compliance with its corporate email policy. The Company accepts > no liability or responsibility for any onward transmission or use of > emails and attachments having left the Astex Therapeutics domain. Unless > expressly stated, opinions in this message are those of the individual > sender and not of Astex Therapeutics Ltd. The recipient should check this > email and any attachments for the presence of computer viruses. Astex > Therapeutics Ltd accepts no liability for damage caused by any virus > transmitted by this email. E-mail is susceptible to data corruption, > interception, unauthorized amendment, and tampering, Astex Therapeutics > Ltd only send and receive e-mails on the basis that the Company is not > liable for any such alteration or any consequences thereof. > Astex Therapeutics Ltd., Registered in England at 436 Cambridge Science > Park, Cambridge CB4 0QA under number 3751674 > > > > > > > > -- > Scanned by iCritical. Disclaimer This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have received this communication in error, please notify Astex Therapeutics Ltd by emailing i.tic...@astex-therapeutics.com and destroy all copies of the message and any attached documents. Astex Therapeutics Ltd monitors, controls and protects all its messaging traffic in compliance with its corporate email policy. The Company accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Astex Therapeutics domain. Unless expressly stated, opinions in this message are those of the individual sender and not of Astex Therapeutics Ltd. The recipient should check this email and any attachments for the presence of computer viruses. Astex Therapeutics Ltd accepts no liability for damage caused by any virus transmitted by this email. E-mail is susceptible to data corruption, interception, unauthorized amendment, and tampering, Astex Therapeutics Ltd only send and receive e-mails on the basis that the Company is not liable for any such alteration or any consequences thereof. Astex Therapeutics Ltd., Registered in England at 436 Cambridge Science Park, Cambridge CB4 0QA under number 3751674
