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
[EMAIL PROTECTED]
http://www.phenix-online.org/mailman/listinfo/phenixbb
