Dear Pavel and Frank It is my recollection that one of the primary goals in the creation of the PDB format was the interchange of information between software packages. While it has certainly failed to meet that (difficult) goal it has been useful at least in the interchange between refinement programs, except in the cases where refinement package authors have ignored the specs. That said, my reading of the specs for the PDB format is that the column in question on the ATOM and HETATOM cards is to contain the isotropic B factor of the atom. There already is redundancy in the format, because if there is an ANISOU card defining the anisotropic B the isotropic component is still listed on the ATOM card, not some residual quantity. That said, I DON'T CARE. The most important thing is to get some consistency here so we can pick up a PDB file and have some idea what it contains. I think everyone agrees on the definitions of the elements of the TLS tensors, agrees on what an anisotropic B is, and agrees on what an isotropic b is. All this fight is over is how the numbers are arranged in a simple text file. I have a collection of models I've pulled from the PDB that I can't figure out, and I'm usually pretty good at this stuff. What will the person do who pulls these models twenty years from now, when memories of the idiosyncrasies of today's Phenix and Refmac have been forgotten? Please, could the authors of Phenix, Restrain, and Refmac get together and agree on something? I'm confident that the wwPDB would go with whatever is agreed upon. Dale Tronrud 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.
--- 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
_______________________________________________ phenixbb mailing list [email protected] http://www.phenix-online.org/mailman/listinfo/phenixbb