 |
 |
On Thursday, March 03, 2011 05:10:02 am Judith Reeks wrote: > Dear Eleanor, > > I don't think that was the case. I add "tlsd waters exclude" to a > refinement which as I understand it should prevent that. Also, I checked > the output files and the TLS groups only involve my protein, waters and > ligands aren't included anywhere. I can't explain why my TLS restraints > were giving me problems. Without looking at your files I can't be certain, but.... The usual problem is that refmac applies clipping limits to B factors. In the absence of TLS, this means that the minimum allowed B is (by default) 2.0 and the maximum is (I think) 200. So far. so good. But in the presence of a TLS model, these same clipping limits are applied to the _incremental_ Biso values, and that's just wrong. I.e., if the current set of TLS parameters over-estimates B for some particular atom, the density gradient will try to drive the incremental B value for that atom negative to compensate. But the program doesn't let that happen. The result is that the incremental B values bottom out at 2.0 and the refinement goes pear-shaped. I think the simplest fix for this would be to have refmac detect that it has happened and modify the current TLS parameters to shift all the predicted B values downward. That way the required incremental Biso become >0 and the problem is avoided. An alternative, but more difficult to implement, fix would be to let the incremental B values go negative. The paired *.pdb and *.tlsin files output by the TLSMD server specifically avoid this problem: the TLS parameters are chosen such that the incremental B values required to best reproduce your input model are always positive. But as you continue refinement this criteria may gradually be lost, and as noted above refmac doesn't currently detect or fix this for you. Ethan > > Regards, > > Judith > > On 03/03/2011 10:49, Eleanor Dodson wrote: > > I think you have been caught by a new REFMAC "feature" which tries to > > design its own TLS groups including linked H2Os and ligands. > > > > Check your tls output records and see what it has clustered into a > > group.. > > > > I am not sure how to disable this - at times I want to override any > > automatic selection.. > > Eleanor > > > > On 03/01/2011 07:48 PM, Judith Reeks wrote: > >> Dear All, > >> > >> Thank you for your suggestions. Many of you asked what the occupancies > >> were in the region and they were all one, so partial occupancy was not > >> the problem. > >> > >> I was using TLS restraints during the refinement when this problem > >> happened. Given the suggestions that TLS may be a problem and that might > >> be causing the low B-factors, I went back and re-ran the refinement > >> without TLS and the problem disappeared. Then I submitted my latest file > >> to the TLSMD server for new restraints and the next round of refinement > >> got rid of the problem. The B-factors increased to normal levels (~15 > >> compared to ~5 before) so it seems to have done the trick. > >> > >> Thank you to everybody for their help, > >> > >> Judith Reeks > >> > >> [log in to unmask] > >> > >> School of Chemistry > >> > >> University of St Andrews > >> > >> > >> On 01/03/2011 17:28, Mark Robien wrote: > >>> Hmm - kinda interesting > >>> > >>> In addition to the sorts of things suggested by Mark van Raaij, older > >>> versions of Refmac > >>> were prone to have a phenomenon with B factors - once they get over a > >>> certain level, the algorithm > >>> has a very hard time bring them back down, even when the data suggests > >>> it. > >>> > >>> I've usually seen it with much higher B factors than you seem to have > >>> here - for example, loops where the B's > >>> are actually 40-60, but previous rounds of refinement have the B > >>> factors 60-80 or higher. > >>> Judging from the coot screen & the residues you are focusing on, I > >>> doubt that is the answer (unless you also > >>> have a TLS model, in which case I'd wonder). If you do have TLS - > >>> well, things get more complicated; for example, > >>> is this the edge of a TLS domain? > >>> > >>> Nonetheless, you could try the solution for the problem that I > >>> describe - which is to reset all the B factors to a (very) > >>> low B factor - maybe even as low as 2.0 (lower?), and then another > >>> round of refmac - with a sufficient number of > >>> cycles - will re-refine the B (and xyz), thus escaping the region of > >>> refinement space that has a very weak gradient. > >>> > >>> A variant approach that might be appropriate - similarly reset the B > >>> for the (?small) region of your model that has the problem. > >>> > >>> Sadly, it's been awhile since I did any refinement myself - but the > >>> uppsala suite had some of the nicer tools for resetting B within pdb > >>> files, without having to do it manually (ugh - not appealing) - or > >>> writing an adhoc awk script (a very easy alternative, if you're > >>> familiar enough). > >>> > >>> Mark Robien > >>> > >>> > >>> On 3/1/2011 10:32 AM, Judith Reeks wrote: > >>>> Dear All, > >>>> > >>>> I am currently refining a structure using the latest experimental > >>>> version of Refmac (5.6) and there seems to be a problem with my Fo-Fc > >>>> map. There is a region where I have fitted residues to the electron > >>>> density but after refinement there is still positive electron density > >>>> assigned to the region despite the fact that residues fit the > >>>> electron density (see link below for a screenshot). Multiple rounds > >>>> of refinement have yet to get rid of this problem. I have checked the > >>>> PDB file and there does not appear to be any problems with this > >>>> region. Has anybody seen something like this before? > >>>> > >>>> http://i1083.photobucket.com/albums/j382/jreeks/Screenshot2011-03-01at1613402.png > >>>> > >>>> > >>>> > >>>> Regards, > >>>> > >>>> Judith Reeks > >>>> > >>>> [log in to unmask] > >>>> > >>>> School of Chemistry > >>>> > >>>> University of St Andrews > >>>> > >>> > >> > > > -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742