Hi Dale,
as I've mentioned before, another source of discrepancy in
reproducing R-factors could be a different treatment of the bulk
solvent correction in the refinement program and in sfcheck. The
sfchelc manual says:
<snip>
SFCHECK applies the "soft" low resolution
cut-off to structure factors according to the formula:
Fnew = Fold (1-exp(-Boff*s2)) , where Boff = 2dmax2
<snip>
This type of bulk solvent correction might be quite different to the
mask bulk solvent correction that is typically applied in REFMAC, CNS
and PHENIX.REFINE.
Best regards,
Dirk.
Am 18.03.2008 um 01:20 schrieb Dale Tronrud:
Hi again,
I guess this is only a partial summary, since I still don't
understand
all the issues this question raises.
Pavel Afonine reported that his extensive tests of the PDB reveals
that
reproducing R values from models with TLS ADP's is a wide-spread and
serious problem. The principal problems (IMHO) are
1) Incorrect or illegal TLS definitions in the REMARK.
2) Some files list in the ATOM "B" column the residual B after TLS
has been accounted for while others list the total B (TLS and
residual). There is no clear indication in the PDB file which
interpretation is being used.
Tassos, Eleanor, and others recommended taking the TLS definition from
the PDB header and running zero cycles of unrestrained refinement in
Refmac to get it to calculate R factors and Maps w/o the need to
define
ideal geometry for co-factors. I have yet to see this work, however
(See below)
Ulrich Baumann wrote to tell me of two of his PDB's that he knows will
give back the reported R values. They are 2qua and 2qub.
I grabbed 2qua from the RCSB server, extracted the TLS groups with
CCP4i,
and found that the TLS definitions were incorrect. There is one
polypeptide
in this model and three TLS groups. The first and third group did not
have a residue range, while the second group defined a residue
range in
the middle of the peptide. I made the assumption that the first and
third TLS groups were intended to cover the beginning and end of the
peptide and corrected the .tls file.
I loaded this into Refmac and asked for zero cycles of unrestrained
refinement and got an R value of 19.4%. The PDB file says it should
be 17.3%. I then asked Refmac to run 10 cycles of TLS and 10 cycles
of restrained refinement and got an R value of 17.5%. Good enough.
From this result I infer that Refmac is unable to calculate the
original
ADP's given this PDB file and TLS definition. It can reconstruct them
via refinement, basically ignoring the B values of the PDB file.
This particular PDB entry appears to contain in its "B" column the
residual B's.
I also tried entry 2qub, but with less luck. This model has seven
peptides and 30 TLS groups. The first seven TLS groups defined in
the header of the PDB cover each of the seven chains, while the other
23 groups had no residue range. I can guess that the intension was
to have five TLS groups for each of the seven chains, but without
additional information from Dr. Baumann, I'm unable to even start
trying to reproduce R values and calculate maps.
So... 1) Pavel is correct, there are many clear errors in the TLS
REMARKs of PDB entries. 2) It seems necessary to ask Refmac to
recreate the ADP description for a PDB entry from scratch, assuming
the TLS group definition can be deduced from the PDB header. This,
currently, requires refinement which requires .cif's for the unusual
groups.
If CCP4I could ask Refmac to perform only TLS/B refinement, holding
positions fixed, the need for detailed .cifs would be greatly reduced.
I have no desire to move the atoms anyway.
Better yet, if someone could find out what Refmac is expecting to find
in its starting PDB (what it wants in the "B" column) one could add
a tool to CCP4I that could convert a PDB entry to what Refmac wants
w/o refinement. Since there appear to be two varieties of entries
one could try both possibilities and choose the one with the lowest
R value.
I have to close with additional problems, I'm afraid. I can't run
the required refinement on 1nkz to test TLS/B refinement but
I have tried it on 3bsd, where I have a good .cif for the Bchl-a
groups. When I pull out the TLS definition, and perform 10 cycles
of TLS and 10 cycles of restrained refinement I get an R value of
20.2% while the entry asserts that the correct value is 17.8%. The
final TLS parameters look, by eye, pretty similar to the deposited
ones, so I don't know what is going on here.
Dale Tronrud
Dale Tronrud wrote:
Hi,
I am looking over a number of models from the PDB but have been
unable to reproduce the R-factors for any model that was refined
with Refmac and contains TLS parameters. I usually can't get within
5% of the reported value. On the other hand, I usually do pretty
well for models w/o TLS.
An example is the model 1nkz. The PDB header gives an R value
of 17% but even when I use tlsanal in CCP4i to generate a PDB with
anisotropic B's that mimic the TLS parameters I get an R value of
22.4% using SFCheck. (I'm not implying that I suspect any problem
with 1nkz, in fact I have every reason to believe this is the great
model its published stats indicate.)
I've found a CCP4 BB letter that stated that SFCheck does not
pay attention to anisotropic B's but that letter was dated 2002.
I hope this limitation has been removed, or at least the output
would mention this limitation.
Setting up a refinement in Refmac involves a large overhead,
since even for zero cycles of refinement the program insists on
a complete stereochemical definition for the strange and wondrous
groups in this model. I would just like to verify the R factor
and calculate a proper map for inspection in Coot. Since I have
many models I would like to look at, I would like a simple procedure.
I did set up a Refmac run for another model, for which I do
have all the .cif's required, but even after refinement I was not
close to the reported R.
I see that the models I'm interested in are not present in the
Electron Density Server, so I suspect I'm not alone in fighting
this battle.
Any advice would be appreciated,
Dale Tronrud
*******************************************************
Dirk Kostrewa
Gene Center, A 5.07
Ludwig-Maximilians-University
Feodor-Lynen-Str. 25
81377 Munich
Germany
Phone: +49-89-2180-76845
Fax: +49-89-2180-76999
E-mail: [EMAIL PROTECTED]
*******************************************************
