True enough. My comment was in the context of whether it is better to deposit ANISOU lines as a representation of the anisotropy.
The default for BRES in TLSANL is indeed false. This was originally done so as not to break the pre-existing RESTRAIN usage. This is taken care of in the GUI, and for those using the command line, it is in the doc and in the examples. Cheers Martyn On Mon, 2008-03-31 at 17:34 +0100, Ian J. Tickle wrote: > <[EMAIL PROTECTED]> > A<[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > From: "Ian Tickle" <[EMAIL PROTECTED]> > To: "Winn, MD (Martyn)" <[EMAIL PROTECTED]>, <CCP4BB@JISCMAIL.AC.UK> > Return-Path: [EMAIL PROTECTED] > X-OriginalArrivalTime: 31 Mar 2008 16:34:19.0370 (UTC) > FILETIME=[1165ACA0:01C8934D] > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Winn, MD (Martyn) > > Sent: 29 March 2008 20:56 > > To: Robbie Joosten; CCP4BB@JISCMAIL.AC.UK > > Subject: RE: [ccp4bb] Rant: B vs TLS, anisou, and PDB headers > > > > I believe the simplest and most honest thing to deposit are > > the parameters of your model, > > viz the TLS parameters and the residual B factors. > > Derived quantities should be calculated as and when you need them. > > > > m > > What the parameters of the model are depends on how you calculate the > structure factors. I could equally well define the total Uaniso that > goes into the SF calculation as: > > Uaniso_from_TLS - diagonal_U_from_trace + diagonal_U_from_Biso > > in which case the parameters are the TLS parameters and the full Biso's. > In fact this is precisely what the Restrain program, which originally > implemented TLS for PX refinement, did. I never did understand the > rationale to change this, because it seemed to go against the spirit of > the ATOM/ANISOU records, where the Biso column contains the full Biso > regardless of whether or not an ANISOU record is present. Also I see > that the TLSANL program, which was originally developed for use with > Restrain, has the option BRESID to select residual or full Biso's in the > PDB file, but the default is apparently (if we are to believe the > documentation!) BRESID = false, i.e. assume full Biso's. This surely is > another source of potential confusion. > > I think the onus is on program developers to maintain compatibility with > pre-existing software (that was always something we were always > cognisant of when we were developing Restrain), unless of course there > are cogent reasons not to, but in this case I don't see compelling > reasons to be incompatible. I think you deviate from compatibility at > your peril! > > Cheers > > -- Ian > > > 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 [EMAIL PROTECTED] > 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 > -- *********************************************************************** * * * Dr. Martyn Winn * * * * STFC Daresbury Laboratory, Daresbury, Warrington, WA4 4AD, U.K. * * Tel: +44 1925 603455 E-mail: [EMAIL PROTECTED] * * Fax: +44 1925 603825 Skype name: martyn.winn * * URL: http://www.ccp4.ac.uk/martyn/ * ***********************************************************************
