From: Luca Pellegrini
Date: 10 January 2012 13:25
Dear all,
A minor point but worth mentioning, I think...
The EDS server does not produce a density map for PDB entries for which it cannot calculate R-factors within 5 percentage points of the published values. I understand that the server was set up in the dark ages of crystallographic refinement, when people perhaps took some liberties with their refinement protocols. Hopefully, the educational point now has been made so wouldn't it be better to calculate the map together with a warning of the discrepancy in R-factor values?
Coot does display a map for such a PDB entry, but with a pop-up window warning the user that "This is not a reliable map." Without explanation, this statement is at least as unreliable as the map that it refers to and bound to confuse and alarm the user who - in the large majority of cases - finds himself/herself staring at a perfectly decent (reliable?) map.
Luca
Luca Pellegrini
Date: 10 January 2012 13:25
Dear all,
A minor point but worth mentioning, I think...
The EDS server does not produce a density map for PDB entries for which it cannot calculate R-factors within 5 percentage points of the published values. I understand that the server was set up in the dark ages of crystallographic refinement, when people perhaps took some liberties with their refinement protocols. Hopefully, the educational point now has been made so wouldn't it be better to calculate the map together with a warning of the discrepancy in R-factor values?
Coot does display a map for such a PDB entry, but with a pop-up window warning the user that "This is not a reliable map." Without explanation, this statement is at least as unreliable as the map that it refers to and bound to confuse and alarm the user who - in the large majority of cases - finds himself/herself staring at a perfectly decent (reliable?) map.
Luca
Luca Pellegrini
----------
From: Paul Emsley
I believe that the maps are not available via the web server interface. Some people still do... The maps *are* calculated (AFAIK). What would you rather it say, I'm happy to change the message. "The EDS does not think that this is a reliable map, in that it is or may be inconsistent with what the authors were looking at during deposition"? Mark Harris got in touch with me. He himself had been contacted by an (irate?) depositor of a lactose permease who was aggrieved that the map one could download from the EDS via Coot had no indication about it that the map was different to the one he was looking at. That, at least, was what I understood the complaint to be about.
So Coot now accesses the EDS page for each accession code now and screen scrapes it to determine if the EDS gives a convention statistics page - or a warning about unreliability. I'm sorry that that was not good enough.
Paul.
----------
From: Boaz Shaanan
By "calculated" do you mean Fc maps? I thought the maps were 2mFo-DFc of mFo-DFc (at least that's the prompt you get when you ask for a map).
Boaz
Boaz Shaanan, Ph.D.
----------
From: Gerard DVD Kleywegt
There can be many different reasons why EDS calculates an R-value that is different from the one reported by the authors - some of these are listed here: http://eds.bmc.uu.se/eds/eds_help.html#PROBLEMS
Back in the "dark ages" (actually, the late 90s) we arbitrarily decided to use a tolerance of 5 percentage points. If the difference is greater, we assume that -as some people have subtly put it- we are a bunch of incompetent morons who can't even calculate a map, and we choose not to make the maps and statistics derived in the process of calculating them available. So, if anything, the phrase "unreliable map" means just that - we cannot be sure that we have done a good job at calculating the map, and would rather be safe than sorry.
Once upon a time, we asked crystallographers to help us trace the causes of any discrepancies for their entries so that we could improve EDS and the public archive. However, no good deed goes unpunished (ask Colin), and this request resulted in so much abuse from several prominent crystallographers (incl. a Nobelist) that we abandoned that effort. (I don't think any of them had actually tried to download the coordinates and structure factors from the PDB and calculate maps from those themselves... one of them subsequently tried and found himself unable to reproduce his own R-value...)
Nowadays, EDS in Uppsala is unfunded and unstaffed. It is an automatic script that runs every weekend. Obviously, that means that we cannot offer support, let alone do new development work. In the future, EDS will rise from its ashes at PDBe - at that stage, we can reconsider many choices we made for the Uppsala version and will also have resources to maintain and support it properly.
--Gerard Best wishes,
--Gerard
----------
From: Luca Pellegrini
Hi Paul,
How about "Warning: the R-factor calculated for this map differs significantly from the published R-factor"?
Then we can discuss what is significant ;-)
----------
From: Frank von Delft
Or just print both Rfactors...?
----------
From: Pavel Afonine
This is what phenix.model_vs_data does, leaving for you to decide if the difference is "significant":
Pavel
----------
From: Robbie Joosten
Hi Frank,
EDS already does that. Even so, reproducing the R-factor does not prove that
the map is reliable. See for instance 3frk for which the deposited dataset
is much smaller and less complete than the one used for refinement. The map
from EDS is therefore completely model biased.
I only recently started looking for this problem of lower-than-reported
completeness with. I have not found a lot of cases, but already too many.
Fortunately, at least a few depositors deposited the rest of the dataset
after I sent a bug report to the PDB (e.g. 3mbs).
Cheers,
Robbie
----------
From: Ed Pozharski
There are many reasons why one could get the gap in R-values. As the
proud author of an "unreliable" map myself (3pht), I found that what did
it was that the TLS-refined model was deposited with the full B-factors
(per PDB reqs). Since the EDS scripts are smart enough to detect the
TLS records and apply them, the R-values were way off. It also did
wanders to the metal ions that were (perhaps mistakenly) not included in
the TLS groups.
Curiously, this often happens to really good high res structures (e.g.
the largest subangstrom structure ever solved, 3ju4 mentioned in the
other thread). I suspect the deal is the software mismatch, as it was
refined with SHELX to R~11%, and without fine-tuning the refmac
refinement one gets R~16%.
Results are often much more consistent at pdb_redo, given that it
actually refines the models. For instance, 3ju4 is reported at R~11%.
The maps look cleaner too.
On a personal note, I must say that I had very positive experience
remediating the 3pht entry at EDS.
Cheers,
Ed.
--
After much deep and profound brain things inside my head,
I have decided to thank you for bringing peace to our home.
Julian, King of Lemurs
No comments:
Post a Comment