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).
