Hi Andrew,
1. Some boundaries give much worse or even unstable refinement whereas others
give perfectly reasonable results. There seem to be real sweet spots for TLS
group selections; the question is whether these relate to the mechanics of the
structure. The system is well enough determined if the choice of 'system' is
good, even with the same amount of parameters.
2. It's been a while and many Refmac versions ago since I saw this for two
connected TLS groups (I usually use very conservative TLS group selections with
few, if any, connections). But as soon as I leave out specific connected
residues from TLS altogether (option 3) the results can be worse. I have
recently been fighting with a particular case where not including a sugar tree
in TLS completely messes up the B-factors. The coordinates are quite reasonable
though, so validation of the B-factors is really needed.
Cheers,
Robnie
Sent from my Windows Phone
________________________________
Van: Andrew Leslie
Verzonden: 22-8-2013 10:01
Aan: Robbie Joosten
CC: CCP4BB@JISCMAIL.AC.UK
Onderwerp: Re: [ccp4bb] TLS group assignment near poorly ordered loop
Hi Robbie,
I was interested in a couple of things in your response:
1. Slightly different boundaries giving surprisingly different results.
Doesn't this suggest that the system is too poorly determined to justify using
TLS (and there is the issue that Ethan Merritt has raised many times about the
problems at the junctions of TLS groups).
2. Getting very large differences in B-factors of connected atoms.
I have not seen this problem using refmac, although I have seen it on several
occasions when structures are refined with PHENIX refine, especially at lowish
resolution. Quite possibly there are PHENIX parameters that one can change to
minimise this effect (apart from using one B-factor for a group of atoms), I'm
not sufficiently familiar with the program.
I think that I would personally go for option 3, as the anisotropy may well be
different for the different conformities that the loop can adopt, and in any
case it sounds as if it is not sufficiently well determined to justify adding
parameters.
However, as you suggest, the best thing is probably to try all options and see
if the data can really discriminate between them.
Cheers,
Andrew
On 21 Aug 2013, at 22:14, Robbie Joosten <robbie_joos...@hotmail.com> wrote:
> Hi Shane,
>
> Option one and two may both work. The extra group is not a problem unless it
> doesn't actually improve the fit with the data much. If you really have very
> little data, you should consider first using one overall residual B-factor
> and try to get the most out of the TLS. You can try refining with slightly
> different boundaries for the loop and then use the Parvati server to see
> which gives the most sensible results. They can be surprisingly different.
> Option three has can give unlikely results such as very large differences in
> B-factors of connected atoms. It may give nice results (try and see), but
> option 1 and 2 will probably work much better.
>
> Cheers,
> Robbie
>
>
>> -----Original Message-----
>> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
>> Shane Caldwell
>> Sent: Wednesday, August 21, 2013 22:44
>> To: CCP4BB@JISCMAIL.AC.UK
>> Subject: [ccp4bb] TLS group assignment near poorly ordered loop
>>
>> Hi bb,
>>
>>
>> I have a question about TLS group assignment. I have a loop that is poorly
>> ordered. The backbone can still mostly be built, though that's probably
> just
>> the predominant conformation of many. TLSMD usually assigns a group
>> border on one or both sides of this loop, though the assignment isn't
> always
>> consistent. Given that I know the loop is poorly ordered, it might not be
>> appropriate to allow it to share TLS parameters with the adjacent well-
>> ordered regions. The way I see it, there are 3 options:
>>
>>
>> 1. Allow the loop to continue to be integrated into a larger TLS group
>> (probably not ideal)
>>
>> 2. Assign the loop it's own TLS group
>>
>> 3. Omit the loop from TLS assignment entirely (i.e. skip those residues in
> the
>> .tlsin file)
>>
>>
>> (2) seems the most reasonable to me, but introduces more parameters that
>> probably aren't meaningful and may contribute to overfitting. On the other
>> hand, I don't know if (3) is scientifically sound and/or will lead to
> problems
>> refining in refmac. What would be my best option?
>>
>>
>> Interested to hear thoughts on this, thanks!
>>
>> Shane Caldwell
>>
>> McGill University
