[phenixbb] Rant: B vs TLS, anisou, and PDB headers
Frank von Delft
frank.vondelft at sgc.ox.ac.uk
Sat Mar 29 12:35:55 PDT 2008
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 (I still don't).
I'm latching onto Garib's philosophy (or how I understood it), which is
intuitively extremely appealing: what I want to build, deposit, and see
density of is the *protein molecule*. How that molecule breathes,
packs, and misbehaves crystallographically I don't really care, but can
be modelled and refined explicitly, as operations necessary to generate
the observed diffraction.
(Similar to what Sharp calculates: the phases of the *general
protein*. How this protein changes from one derivative to the next is
modelled explicitly and separately, and thereby refined.)
And so, the *protein molecule* is described by the ATOM/ANISOU cards,
the rest in the header. It's probably separate internally in
phenix.refine anyway, so don't mangle it all when you write it out:
That said, just my suggestion, and I agree with Dale: WHATEVER, JUST DO
THE SAME THING.
Pavel Afonine wrote:
> 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 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
>> 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 :)
>> phenixbb mailing list
>> phenixbb at phenix-online.org
> phenixbb mailing list
> phenixbb at phenix-online.org
More information about the phenixbb