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

[Pavel Afonine]

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 are necessary);
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 information from PDB header to compute R-factors, 
but ALL programs can read ATOM records.
3) Residual B-factors should obey Hirshfeld's rigid bond test (minus 
deviations due to internal rotational degrees of freedom), so writing a 
flat distribution of residual B into ATOM record is not really informative.

I'm sure I had in mind more, but this is what immediately comes to my mind.

phenix.refine writes the complete TLS information into PDB file header. 
This is not the duplication but a way to compute the residual B-factors 
for those who really wants to do this.

phenix.refine writes out a complete information set into PDB file header 
under REMARK 3, ready-to-deposit into PDB. It is up to PDB how to treat 
this information.

Doing refinement in phenix.refine it is not assumed that the user jumps 
back and forth between refinement packages, so no special effort is made 
to assure easy and straightforward transferability of refinement states 
/ results between refinement packages.

Reasons to write out residual B-factor:
- I do not see any.

Thanks for bringing this up.
All the best!
Pavel.

---
Pavel V. Afonine, Ph.D.
Lawrence Berkeley National Lab, Berkeley CA, USA (http://www.lbl.gov/)
CCI: Computational Crystallography Initiative (http://cci.lbl.gov/)
PHENIX (http://phenix-online.org/)



On 3/29/2008 10:35 AM, Frank von Delft wrote:
> 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, Refmac writes residual ADP.
> * Refmac writes a remark -- pdbdep strips it (!?!!?)
> * Phenix writes no remark (I think?)
> * Refmac writes different numbers to TLSOUT and pdb header (trace of S)
> * Phenix duplicates the information in header (TLS) and ANISOU cards, 
> the latter thereby making implicit what should be explicitly stored:  
> how the ADPs are connected.
> * Refmac, given phenix TLS-originating ANISOUs, flattens them into first 
> number, but does not remove them
> * PDB does not care
>
>
> I'd like to appeal for an urgent consensus -- which should be unusually 
> easy, since it involves only two programs and one repository.
>
> My strong recommendation, from first principles of usability:  residual 
> B into ATOM, no TLS in ANISOU, and the rest into the header.  I know 
> it's religious, but here's the reasoning: 
> ==> the end-user looks *locally*, that's what ATOM and ANISOU are for. 
> ==> global stuff (cell, symmetry, NCS, and yes, TLS) belongs in the 
> header -- as do what's still missing, namely twinning, lattice 
> modulations, scatter factors, and restraints.
>
> Yes, we crystallographers want easy B-factor stats (phenix's reason), 
> but then lets fix the analysis programs to look at the header as well.  
> And yes, packing and internal motions (TLS) are all very important for 
> analysis - but that is why it should be explicit in the header, so that 
> graphics tools have easy access to it.
>
> End rant (but not end hope :)
> phx.
>
>  
>
>
> _______________________________________________
> phenixbb mailing list
> phenixbb at phenix-online.org
> http://www.phenix-online.org/mailman/listinfo/phenixbb
>