We do have to mess with the PDB format every time something new is
invented. Usually it's just REMARK 3 that has to be changed, but you
always need to put some kind of remark in the header that you used a
certain type of refinement.
When different types of anisotropic refinement are combined (say: TLS
for the peptide, single atom for a few ions, the thing you are working
on for ligands, etc), it becomes very difficult to figure out what the
depositor did. ANISOU records alone won't do. We need reliable headers
to be able to reproduce the results. I agree that ANISOU records are a
great way to model ADPs in a general way. However, I think it's better
to not mix different layers of B-factor information. You are likely to
throw away information when you do.
Cheers,
Robbie Joosten
Kevin Cowtan wrote:
I agree with Paul and George that it is vital that PDB files from TLS
refinement contain ANISOUs which reflect the results of that refinement,
and would like to reinforce Paul's point below.
There are many possible parameter-frugal approximations to full
ADP-refinement: TLS is just one of them. I have another sitting on my
desk waiting for implementation. So concentrating on TLS-specific
solutions is a mistake.
Storing the estimated ANISOUs is the correct solution, otherwise we have
to mess with the PDB format every time we come up with a new way of
refining ANISOUs.
Ideally, each refinement program should be able to read the ANISOUs from
a PDB file and interpret them in terms of its own anisotropy model -
either guessing TLS groups from the data, or picking its own
automatically, or using any other scheme it implements.
Paul Adams wrote:
- Allowing ANISOU records only when atomic anisotropic displacement
parameters
have been refined seems very restrictive. There may be multiple ways
to arrive
at anisotropic displacements other than the traditional method (TLS
is one,
George mentioned TLS restraints instead of constraints, and we have
some ideas
about ADP refinement that would also result in anisotropic
displacements).
