At the risk of throwing a little gasoline on the flame war, what about side chains that will ALWAYS poke outside of the electron density? For example, pretty much any terminal aliphatic at 3.5 A resolution? I first learned this about 15 years ago when I made this movie:

http://bl831.als.lbl.gov/~jamesh/movies/resolution.mpeg

For those of you whose browser no longer supports MPEG-1, this is a movie of a calculated (aka noise-free) electron density map, contoured at "1 sigma", but cut to the resolution shown after applying an overall B factor sufficient to suppress series-termination. By that I mean the maps don't look all that different with or without the cutoff. The coordinates shown are the "correct" model used to calculate the map. At about 3.5 A you start to see side chains poking out of the density, and at 6 A, all the side chains are "gone". Does this mean they should be modeled with zero occupancy? ;)

-James Holton
MAD Scientist


On 4/3/2011 9:57 PM, Maia Cherney wrote:
I guess, most hydrophilic side chains on the surface are flexible, they don't keep the same conformation. If you cut those side chains off, the surface will be looking pretty hydrophobic and misleading (and very horrible). I prefer to see them intact. I know, most of them are flexible and don't have one exact position, but it's OK. I know they are there not far from the main chain. Usually, their exact position is irrelevant.

Maia



Jacob Keller wrote:
Well, what about getting the default settings on the major molecular
viewers to hide atoms with either occ=0 or b>cutoff ("novice mode?")?
While the b cutoff is still be tricky, I assume we could eventually
come to consensus on some reasonable cutoff (2 sigma from the mean?),
and then this approach would allow each free-spirited crystallographer
to keep his own preferred method of dealing with these troublesome
sidechains and nary a novice would be led astray....

JPK

On Sun, Apr 3, 2011 at 2:58 PM, Eric Bennett <er...@pobox.com> wrote:
Most non-structural users are familiar with the sequence of the proteins they are studying, and most software does at least display residue identity if you select an atom in a residue, so usually it is not necessary to do any cross checking besides selecting an atom in the residue and seeing what its residue name is. The chance of somebody misinterpreting a truncated Lys as Ala is, in my experience, much much lower than the chance they will trust the xyz coordinates of atoms with zero occupancy or high B factors.

What worries me the most is somebody designing a whole biological experiment around an over-interpretation of details that are implied by xyz coordinates of atoms, even if those atoms were not resolved in the maps. When this sort of error occurs it is a level of pain and wasted effort that makes the "pain" associated with having to build back in missing side chains look completely trivial.

As long as the PDB file format is the way users get structural data, there is really no good way to communicate "atom exists with no reliable coordinates" to the user, given the diversity of software packages out there for reading PDB files and the historical lack of any standard way of dealing with this issue. Even if the file format is hacked there is no way to force all the existing software out there to understand the hack. A file format that isn't designed with this sort of feature from day one is not going to be fixable as a practical matter after so much legacy code has accumulated.

-Eric



On Apr 3, 2011, at 2:20 PM, Jacob Keller wrote:

To the delete-the-atom-nik's: do you propose deleting the whole
residue or just the side chain? I can understand deleting the whole
residue, but deleting only the side chain seems to me to be placing a
stumbling block also, and even possibly confusing for an experienced
crystallographer: the .pdb says "lys" but it looks like an ala? Which
is it? I could imagine a lot of frustration-hours arising from this
practice, with people cross-checking sequences, looking in the methods
sections for mutations...

JPK




Reply via email to