*** For details on how to be removed from this list visit the ***
*** CCP4 home page http://www.ccp4.ac.uk ***
On Wednesday 05 July 2006 01:24 am, Donnie Berkholz wrote:
I'm starting with an anisotropically refined protein. The problem is
that for each atom, the anisotropic B is a combination of many
different scales of motion, from global or domain-level to very
local. I would like to be able to separate these levels by first
"factoring out" motions common to _all_ atoms from the single-atom
anisotropic B's into larger TLS groups, then motions common to large
domains, and so forth.
This would define different layers or shells of TLS domains -- a
global domain for global movements, then within that, various
sub-domains for smaller-scale movements, and so forth. The "leftover"
or residual anisotropic B would be highly local and would have no
global or large-scale motion effects still contributing to it.
Ah. I understand completely.
Unfortunately, that is currently in the category of "unsolved problems".
Some of the difficulties are discussed in the Acta D TLSMD paper.
For one thing, if you limit consideration to the ADPs alone, then
in the general case a description in terms of nested
TLS groups is mathematically identical to a description in terms of
un-nested groups. You just have to collect and rearrange the terms.
That means it is not possible in general to test for a "better fit"
to a nested vs. un-nested model.
On the other hand, if you bring in outside information
(data or constraints other than a list of atomic coordinates and ADPs)
then more leverage can be brought to bear.
I had hoped to find time to contribute a CCP4 newsletter article
on this topic, but alas for holidays, deadlines, and other projects....
For example, suppose you have a small loop waving about on the side
of a large rigid domain. Left to itself, TLSMD will find a 3-group
model that puts the loop in one group and puts the two remaining
segments of the large domain in two additional groups.
Clearly merging these latter two groups into a single noncontiguous
TLS group would yield a more parsimonious description (fewer free
parameters). This currently requires manual inspection and
interpretation of the TLSMD output, although we have made a start at
adding semi-automated guidance. If you drill down through the TLSMD
output to the "detailed analysis" pages for any given partition,
you will find a cross-prediction matrix that basically shows how
well different TLS groups in the current breakdown agree with each
other. In this hypothetical example one would expect that the two
groups flanking the small loop would cross-predict each other's ADPs
relatively well, since by hypothesis they are in fact both parts of
a single relatively rigid domain.
So far, so good. The next thing one would like is a description
of the loop displacement relative to the domain it is embedded in,
rather than relative to the crystal lattice. Here again, this is
mathematically problematic. Perhaps I have been insufficiently
clever so far, but my current understanding is that there is no
unique solution to this problem that can be derived after the fact.
That is, you cannot derive a unique description of relative
displacement starting from a previously-refined TLS description.
There is too much freedom to numerically shift contributions from
one group to another.
Instead one would have to re-cast the underlying refinement against
crystallographic data to deal explicitly with the nested model.
We are working on this, but have no actual code yet.
Alternatively, it may be possible to overcome the lack of a
unique solution by adding external constraints that ensure
conformance to some a priori model of a meta-distribution of ADPs.
Continuing with the above hypothetical case, one might require
that all possible translational component contributions of the
small loop be shifted to the large domain, but conversely the
rotational components are to be maximized. I'm not saying that
this is a reasonable model, but it's an example of an
a priori expectation that could be imposed. We have done some
experimentation with this approach, but have not reached any
conclusion yet about whether it can be made to work usefully.
I welcome suggestions and insight into this problem from
all corners!
Ethan
Does anyone know of some way to do this? I looked at the TLSMD
server, but it didn't seem to do exactly what I want.
The mmLib package and the TLSMD code can probably do what you
want, even if it isn't one of the default output modes of the
server. But I can't offer any more help until I understand better
what you are aiming for.
I hope I've clarified what I want. I've just started using pymmlib
recently for some other work and it's saved me many hours, so I would
be happy to use it again.
Thanks,
Donnie
