*** For details on how to be removed from this list visit the *** *** CCP4 home page http://www.ccp4.ac.uk ***
Currently what happens (someone correct me if I'm wrong!) is that after TLS refinement Refmac outputs a 'residual' Biso in the B column on the ATOM record, i.e. to get the true 'equivalent' Biso you have to add the isotropic contribution from TLS, namely the trace/3 of the calculated U matrix (Restrain differs in this respect: the Biso it outputs is already the true Biso). After running TLSANL using the default ISOOUT=FULL option the output B is the true Biso, regardless of where the file came from (you have to have specified BRESID if you used Refmac). The reasons you need to run TLSANL are 1) the B output from Refmac with TLS is not the true Biso, and 2) simply that most programs (including the PDB's!) don't understand TLS matrices. If you use Refmac and all you're interested in is the equivalent Biso's why not just remove the ANISOU records from the file after TLSANL? (if you had used Restrain you wouldn't even have to use TLSANL as the B column already contains the equivalent Biso). The REMARK records containing the TLS matrices are still presumably still there after running TLSANL should you need them (of course DO NOT use BRESID with this file otherwise the Biso contribution from TLS will be added a second time!). HTH -- Ian > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dirk Kostrewa > Sent: Friday, May 19, 2006 12:50 PM > To: [EMAIL PROTECTED]; CCP4BB > Subject: TLS and coordinate deposition (was Re: [ccp4bb]: 2 > questions:) > > *** For details on how to be removed from this list visit the *** > *** CCP4 home page http://www.ccp4.ac.uk *** > > > Dear Eleaonor and CCP4ers, > > I also thought about publishing coordinates after TLSANL because I > observe quite often that the TLS part is ignored by both users and > programs, although it could make up the main part of the total > individual B-factors. However, depositing a structure, say, at 2.8 > Angstrom with individual ANISOU cards would look so strange > (at least to > me) that I would really shy away from doing this. The > situation would be > somewhat better if one could split the TLS into isotropic components > that could then be added to the individual isotropic Bs upon > deposition, > and remaining anisotropic components, such that the total information > would still correctly reflect the refinement protocol. > Unfortunately, I > don't look through the mathematics behind this enough ... > Maybe, the TLS > experts could comment on this idea? > > Best regards, > > Dirk. > > Eleanor Dodson wrote: > > Pleae note - all format police. > > > > Working format does NOT have the same requirments as an > archival one. > > > > The problem with TLS is that it is not used by many programs. > > A partial solution is to run TLSANL before deposition - > this means that > > the output Biso and ANISOB records are consistent with the > PDB definitions > > > > Eleanor > > > > > > > > > > > > > > Clemens Vonrhein wrote: > > > >> *** For details on how to be removed from this list visit the *** > >> *** CCP4 home page http://www.ccp4.ac.uk *** > >> > >> > >> On Thu, May 18, 2006 at 10:58:52AM -0700, Ethan Merritt wrote: > >> > >> > >>>> A question for the group: is there any push to get TLS parameters > >>>> incorporated into the standard PDB data format? > >>> > >>> The PDB format is dead, it's passed on! This format is no more! > >>> It has ceased to be! It's expired and gone to meet its maker! > >>> If you hadn't wired it into the code of many programs it would be > >>> pushing up the daisies! > >>> > >>> No, really. Extensions to the PDB format itself are highly > >>> unlikely. It exists as a legacy intermediate to the underlying > >>> archival mmCIF-derived database info. > >>> > >> > >> > >> Formats exists to make a specific task easy and > understandable. To me > >> there is a distinction between a working format and a > storage/archival > >> format - since archival of data (consisting of coordinates > as well as > >> a lot of meta-information) is a very different task from > working with > >> X, Y, Z, OCC, B (and a few other things). > >> > >> I don't think the 'one size fits all' approach works well in this > >> case: PDB might be bad for archival but it is easy as a working > >> format, whereas mmCIF is probably great for databases (I'm > no expert > >> there) but I find it difficult to use as a working format. > >> > >> Cheers > >> > >> Clemens > >> > >> > >> > >> > >> > > > > > -- > > **************************************** > Dirk Kostrewa > Paul Scherrer Institut > Biomolecular Research, OFLC/110 > CH-5232 Villigen PSI, Switzerland > Phone: +41-56-310-4722 > Fax: +41-56-310-5288 > E-mail: [EMAIL PROTECTED] > http://sb.web.psi.ch > **************************************** > > 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.
