[ccp4bb] Rant: B vs TLS, anisou, and PDB headers

Just spent an hour trawling docs, BBs (recent threads) and logs to figure out what the hell my B column is telling me (phenix vs refmac vs pdb). Oh dear, it's a disaster area, quite Heissenbergian... the most important number (uncertainty) is itself unknowable: * Phenix writes total ADP,

Re: [ccp4bb] Problem with the DLS instrument

Dear Yingjie, This does not answer your question directly but we had a similar problem with our DynaPro purchased from Protein Solutions. Most likely this is due to an optics misalignment or a dead laser. Protein Solutions' products are now available in the US through Wyatt Technology

Re: [ccp4bb] [phenixbb] Rant: B vs TLS, anisou, and PDB headers

Dear Frank, it's not a secret that phenix.refine ALWAYS writes total B-factor into ATOM records, there are strong reasons for this and this is clearly stated in the manual. Reasons to write total B-factor: 1) Easy analysis (Easy color by B-factor in graphics: no prior model manipulations

Re: [ccp4bb] [phenixbb] Rant: B vs TLS, anisou, and PDB headers

Hi Pavel All your reasons are there for the convenience of the *crystallographer*, mine are for the end user (=unsuspecting biologist) -- who doesn't know TLS even exists (none of used to), never mind about Hirshfeld's test and how it relates to TLS (I didn't), and certainly not how run it

Re: [ccp4bb] [phenixbb] Rant: B vs TLS, anisou, and PDB headers

2) All you need to reproduce the R-factors are the ATOM records and structure factor formula (and not ATOM records, PDB header with TLS records that sometimes may be lost or manipulated and specific converting programs to add TLS contribution). Also note, that not all programs extract TLS

Re: [ccp4bb] [phenixbb] Rant: B vs TLS, anisou, and PDB headers

Hi Frank, Hi Frank, All your reasons are there for the convenience of the *crystallographer*, mine are for the end user (=unsuspecting biologist) -- who doesn't know TLS even exists (none of used to), never mind about Hirshfeld's test and how it relates to TLS (I didn't), and certainly not

Re: [ccp4bb] 3D structure based alignment

Just to point out that the CCP4 wrapper to SSM superpose allows you to specify residue ranges to consider - very useful for multi-domain proteins. See the -s switches in http://www.ccp4.ac.uk/dist/html/superpose.html I'm not clear if this was your issue. Cheers Martyn -Original

Re: [ccp4bb] [phenixbb] Rant: B vs TLS, anisou, and PDB headers

This is exactly what phenix.refine does: it puts all together so you are not expected to have any knowledge about magic TLS matrices in PDB file header, about right programs to convert one into another and so on. In contrast, if one split things apart: Yes, but no non-crystallographer cares

[ccp4bb] Rant: B vs TLS, anisou, and PDB headers

ANISOU records imply that individual anisotropic B-factors were refined. This will cause problems when you try to redo the final refinement: you add loads of parameters all of a sudden. Using ANISOU records may give you more reliable information about the B-factors, but not about the

Re: [ccp4bb] [phenixbb] Rant: B vs TLS, anisou, and PDB headers

On 3/29/2008 1:37 PM, Frank von Delft wrote: This is exactly what phenix.refine does: it puts all together so you are not expected to have any knowledge about magic TLS matrices in PDB file header, about right programs to convert one into another and so on. In contrast, if one split things

Re: [ccp4bb] Rant: B vs TLS, anisou, and PDB headers

On 3/29/2008 1:25 PM, Robbie Joosten wrote: ANISOU records imply that individual anisotropic B-factors were refined This is not always true. Pavel.

Re: [ccp4bb] [phenixbb] Rant: B vs TLS, anisou, and PDB headers

I think that it is essential that the PDB file that actually gets deposited contains ANISOU records that have had the isotropic contributions added already, and that the B on the atom record is one third of the trace of the orthogonalised Bij tensor that can be derived from the ANISOU record,

Re: [ccp4bb] Rant: B vs TLS, anisou, and PDB headers

Yep, agree completely! My point was that if you try to bypass the TLS parameters, then you still need to retain the anisotropic component somehow. But I wasn't advocating it. I believe the simplest and most honest thing to deposit are the parameters of your model, viz the TLS parameters and

Re: [ccp4bb] [phenixbb] Rant: B vs TLS, anisou, and PDB headers

I suspect there's not going to be consensus on anything except that there needs to be a standardization regarding deposited TLS parameters.Probably the first step is to convince the pdb to not throw away the record describing what's actually in the B-factor column. In my (probably

[ccp4bb] refmac,tlsanl vs TLS, B and anisou

Hi, here's what triggered my earlier rant: I took a pdb from phenix.refine back into refmac, with same TLS definitions, but leaving the ANISOU cards in (accident). I ran this through TLSANL, asking for total B. Refmac has left the ANISOU cards, but all zero except the first element. ATOM

Re: [ccp4bb] refmac,tlsanl vs TLS, B and anisou

Some comments: - We (the PHENIX developers) are working with the PDB to come up with a more streamlined deposition of TLS information for PHENIX. There are some other issues that need to be resolved first that have slowed this down a little. - I am in agreement with George (not