problem dealing with microheterogeneity

[Greg Couch]

Open 1ejg or 1cbn in mmcif or pdb format, and then "turn y 90" and you will see a discontinuous ribbon. Chimera has this problem too. The problem is probably related to the fact that there are two residue 22s and two 25s. structure.polymers() is returning multiple polymers, when there should be one.

The mmCIF reader is supposed to connect up the affects residues in parallel and present one of the alternatives to the sequence code. Not sure how that would/should interact with the polymer code.

[Eric Pettersen]

Our basic data scheme simply does not allow for microheterogeneity, which would not only immensely complicate the data, but complicate all analyses based on that data. My stance is that such structures should be split out into separate homogeneous species. That could also be problematic if there is a lot of heterogeneity, since splitting produces a large number of structures in that situation.

I have as yet to hear any complaint about such structures from users of Chimera 1.

--Eric

[Greg Couch]

Consensus is that microheterogeneous residues should be skipped and a warning should be printed.

Analysis of today's mmCIF files finds that there were 155 structures out of 120859 that had microheterogeneity in them, so 0.13%.

[Conrad Huang]

1ejg does not display correctly on the Mac but causes a crash on Windows.

It looks like the PDB record type to look at is SEQADV and the corresponding mmCIF table is struct_ref_seq_dif.

[Greg Couch]

Doesn't crash after recompile.

[Greg Couch]

Changed code to delete the "microheterogeneity" residues instead of incorporating them. If they were to be kept, the alternate residues would need the atoms without alternate locations from the first residue to correctly apply their template. Then the residues would need to be merged so that the residue name and the bonds would change when the alternate location for the residue was set.

[Eric Pettersen]

Milestone renamed