<[log in to unmask]>
A<7D3BC3901B4543D1A590B580971B9239@neuromancer>
<[log in to unmask]>
From: "Ian Tickle" <[log in to unmask]>
To: "Winn, MD (Martyn)" <[log in to unmask]>, <[log in to unmask]>
Return-Path: [log in to unmask]
X-OriginalArrivalTime: 31 Mar 2008 16:34:19.0370 (UTC)
FILETIME=[1165ACA0:01C8934D]
> -----Original Message-----
> From: [log in to unmask]
> [mailto:[log in to unmask]] On Behalf Of Winn, MD (Martyn)
> Sent: 29 March 2008 20:56
> To: Robbie Joosten; [log in to unmask]
> 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 [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
|