Thanks James for your reply. I my naive way, I thought that when doing paired
refinement, it would be sufficient to run several cycles of refinement with
simulated annealing followed by a thorough real space rebuilding. What is your
thought about using the "jiggling" of additional cartesian annealing steps
(phenix) to check the influence of, say, an additional 0.1A outermost shell?
I used paired refinement over a couple of cycles and thoroughly deleted what
was not visible anymore. Less for the removal of bias, but more to increase
degrees of freedom... But now that I read your answer, I have the impression
that this was not enough to remove bias of the sidechains?
matthias
>>> James Holton <jmhol...@slac.stanford.edu> 08/19/17 7:23 PM >>>
Yes, B factors are indeed a super-absorbent sponge for model bias.
Best to re-set those before re-refinement. But you should also do
something with the coordinates, and probably the occupancies too.
My jiffy to add to Graeme's list of options is this script:
http://bl831.als.lbl.gov/~jamesh/scripts/jigglepdb.awk
It has a variety of options, including separate rms shifts for
coordinates, B factors and occupancies (shift=, Bshift=, and Oshift=), and
a special option called "shift=byB" that moves coordinates in accordance to
the atom's B factor. The distribution of the shifts can be Gaussian
(default), Lorentzian or uniform sphere. The latter is useful if you want
to avoid very large shifts (see below). By default, one conformer (i.e. A,
B, C) is randomly given an occupancy of "1" for all residues and all the
other conformers are given zero. This is an attempt to simulate the
cell-to-cell variation of the structure, which can only have one conformer
at a time. If you specify "keepocc=1" this behavior gets turned off. Any
non-zero "Oshift" will add random noise to all occupancies.
I'm sure all this functionality would be easy to re-create using CCTBX
as well.
I've actually played around with "jiggling" pdb files a fair bit.
Turns out that in order to remove "bias" completely you need to kick the
atoms by an rms distance comparable to the relevant resolution. That is,
1.5 A for 1.5 A spots, but also 6 A if you want to un-bias 6 A spots. This
tends to be outside the radius of convergence of most refinement programs.
In fact, kicking atoms by as little as 0.5 A can often result in some side
chains falling into alternate rotamers and the like. Waters can also fall
out of place and drift into nearby pockets of liberated density. You can
do a "cleanup" after re-refinement to correct for such gross errors.
Looking for the largest differences between starting and re-refined models
generally lights these up. But before you "fix" these things you have
to start asking questions about what "bias" really is.
It seems a popular "bias-reduction" approach is to re-run Phaser or
other molecular replacement job, but all that really does is put your model
onto an alternative origin or asu choice. These choices are arbitrary, of
course, and crystallographically equivalent. Once you have corrected for
the origin shift using something like "reforigin" you can see that all your
Phaser run has produced is a slight rigid-body shift relative to where you
started. Hardly a bias-removal technique.
So, what is "bias"? We tend to think of "bias" the same way we think
of "twinning": as a synonym for "evil". Something to be kept out of our
models and data at all costs. But if you think about it a bit you may
realize that even having the backbone structure itself intact is a form of
"bias". As in you are "biasing" your model to resemble the overall fold
you originally assigned to the structure. You may or may not be all that
worried about this. And if you are certain that the main chain trace is
correct, then enforcing it in further analysis is not "bias", it is "prior
knowledge". I suppose knowing the difference between these two things is
what science is all about.
So, I'd say that "resetting" a structure depends on what aspect of the
structure you're trying to test. If you made a mistake in the backbone
trace, or even a rotamer assignment, then doing a 0.5A jiggle isn't going
to reset that mistake. But if your trying to test the influence of data
between 1.5 A and 1.4 A, then I'd say do a jiggle of at least half that
distance.
-James Holton
MAD Scientist
On 8/17/2017 8:40 AM, Robbie Joosten wrote:
*.EmailQuote {
margin-left: 1.0pt;
padding-left: 4.0pt;
border-left: rgb(128,0,0) 2.0px solid;
}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal {
margin: 0.0cm;
font-size: 11.0pt;
font-family: Calibri , sans-serif;
}
a:x_link, span.x_MsoHyperlink {
color: blue;
text-decoration: underline;
}
a:x_visited, span.x_MsoHyperlinkFollowed {
color: rgb(149,79,114);
text-decoration: underline;
}
*.x_MsoChpDefault {
}
div.x_WordSection1 {
}
In most cases resetting the B-factors
would be enough to perturb the model.
Cheers,
Robbie
Sent from my Windows 10 phone
From: Andrew Leslie
Sent: 17 August 2017 17:29
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] "reset" a structure before
re-refinement
Hi Graeme,
You can do this with PDBSET, keyword NOISE
Cheers,
Andrew
> On 17 Aug 2017, at 16:17, Graeme Winter
<graeme.win...@diamond.ac.uk> wrote:
>
> Dear All,
>
> Is there a protocol out there to gently perturb atomic
positions so that re-running refinement can essentially put them
back without bias from the original refinement? In particular, if
trying to perform the Karplus and Diederichs paired refinement
protocol, I do not want to run the lower resolution refinements
with the "memory" of the weak high resolution data present... and
only have the refined structure to work from...
>
> Am using refmac5, but any pdb randomizer would hit the
spot
>
> Many thanks Graeme
>
> --
> This e-mail and any attachments may contain
confidential, copyright and or privileged material, and are for the
use of the intended addressee only. If you are not the intended
addressee or an authorised recipient of the addressee please notify
us of receipt by returning the e-mail and do not use, copy, retain,
distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of
the individual and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this
e-mail or any attachments are free from viruses and we cannot
accept liability for any damage which you may sustain as a result
of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679).
Registered in England and Wales with its registered office at
Diamond House, Harwell Science and Innovation Campus, Didcot,
Oxfordshire, OX11 0DE, United Kingdom
