<[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
