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

Reply via email to