Pointless doesn't use Clipper to write the mtz file, I call the CCP4
lib routines directly
Phil
On 12 Jun 2009, at 22:45, Ian Tickle wrote:
>
> 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: [log in to unmask] [mailto:owner-
>> [log in to unmask]]
> On
>> Behalf Of Martyn Winn
>> Sent: 12 June 2009 20:46
>> To: Ethan Merritt
>> Cc: [log in to unmask]
>> 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: [log in to unmask]
> *
>> * 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 [log in to unmask]
> 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
>
>
|