Hi Robbie
> If it's probability you're after, if there's no density to guide you
> (very common!) you'd have to place all "likely" rotamers that don't
> clash with anything, and set their occupancies to their probability (as
> encoded in the rotamer library).
Which library? The one for all side chains of a specific type, or the one for a specific type with a given backbone conformation? These are quite different and change with the content of the PDB. 'Hacking' the occupancies is risky bussiness in general: errors are made quite easily. I frequently encounter side chains with partial occupancies but no alternatives, how can I relate this to the experimental date? Even worse, I also see cases where the occupancies of alternates sum up to values > 1.00. What does that mean? Is that a local increase of DarmMatter accidentally encoded in the occupancy?
Actually, I wasn't advocating it - I was taking ZO's suggestion to it's logical conclusion to point out the problem, namely deciding what is "most likely". This you underline with your (very valid) question.


> Until the PDB is expanded, the conventions need to be clear, and I
> thought they were:
> High B-factor ==> means atom is there but density is weak
> Atom missing ==> no density to support it.
Unfortunately, it is not trivial to decide when there is 'no density'. We must have a good metric to do this, but I don't think it exists yet. Removing atoms is thus very subjective. This explaines why I frequently find positive difference density peaks near missing side chains. Leaving side chains in sometimes gives negative difference density but refining them with proper B-factor restrainsts reduces the problem a lot. There is still the problem of radiation damage, but that is relatively small. At least refining the B-factor is more reproducible and less subjective than making the binary choice to keep or remove an atom.
(Radiation damage is NOT a "relatively small" problem.)

The fundamental problem remains: we're cramming too many meanings into one number. This the PDB could indeed solve, by giving us another column. (He said airily, blithely launching a totally new flame war.)

phx.

Reply via email to