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
>> [log in to unmask]
>> http://www.phenix-online.org/mailman/listinfo/phenixbb
>>
> _______________________________________________
> phenixbb mailing list
> [log in to unmask]
> http://www.phenix-online.org/mailman/listinfo/phenixbb
|
