Dear All, Because I also re-refine the odd pdb entry, I get the same problems. I think it is annoying that these 'Gremlins' end up in the PDB. But in all fairness, the PDB is always very willing to solve obvious column substitutions and such (at least in my experience).
Unfortunately, there are also quite a few entries for which R cannot be reproduced without an obvious problem. The EDS and PDB_REDO have loads of examples. It is even worse for R-free, many entries do not have an R-free set deposited (http://www.cmbi.ru.nl/WHY_NOT/comments_withcomment.action?scomid=9) or, even worse, an empty set (http://www.cmbi.ru.nl/WHY_NOT/comments_withcomment.action?scomid=10) Cheers, Robbie Joosten Centre for Molecular an Biomolecular Informatics Nijmegen, the Netherlands > Well, either there haven't been any replies yet or my institution's > email server is unhappy with me (if it's email problems, sorry if I'm > duplicating other responses). > >> This instance leaves room for some concern about the verification >> of >> deposited structure factors: what happened here is consistent with the >> hypothesis that the standard-deviation field is ignored entirely, or at >> least that no plausibility check is carried out on the values deposited >> in >> it. > > My experience with re-calculating maps from deposited models and > amplitudes, although non-systematic, leads me to believe that little or > no checking is done on deposited amplitudes. In one instance, the > listed resolution was off by a factor of 10 (listed as ~20 Angstroms for > a ~2 Angstrom structure). In another, the data listed as amplitudes > were actually intensities (at least, treating the data as intensities > allowed me to reproduce the reported R-factor). > > My supposition is that part of the reason for the lack of checks on > amplitude data is the lack of crystallography software that deals > natively with cif formatted data. It would seem to make more sense to > me to make changes on the PDB end (allowing deposition of data in mtz or > cns format, converting to cif internally as needed for archiving) rather > than on the data processing side; since this might allow for easier > sanity checking. > > Pete >
