Bob Hanson wrote: > Rolf Huehne wrote: > >> Hi, >> >> I noticed that in the PDB file of PDB entry '1AMR' there are overlaps >> between different secondary structure record types, e.g.: >> >> HELIX 13 HM PHE A 352 LYS A 355 1 >> TURN 16 T16 ILE A 353 GLN A 356 TYPE I >> >> This was quite unexpected and I searched for such overlaps in all >> remediated PDB format files of the PDB. My script detected overlaps in >> 2032 entries. A text file containing the PDB codes and the corresponding >> number of overlapping residues is (temporarily) available at this URL: >> >> http://www.fli-leibniz.de/~rhuehne/jmol/analyze_sec_struct-2008_02_26b-overlap.txt >> >> (Note: The numbers are not always correct because for simplification and >> speed-up I didn't took into account numbering irregularities in the >> non-border residues of an element, like insertion codes or nice residue >> number sequences like "28,328,29" in entry '1BLB'.) >> >> The full logfile is (temporarily) available at this URL: >> >> http://www.fli-leibniz.de/~rhuehne/jmol/analyze_sec_struct-2008_02_26b-log.txt >> >> Q: Are the Jmol developers aware of this problem? >> >> >> > yes > >> Q: How is or should this be handled by Jmol? >> >> >> > * > * We do turn first, because sometimes a group is defined > * twice, and this way it gets marked as helix or sheet > * if it is both one of those and turn. > * >
So it is handled by using this priority list (helix/sheet inferred from example '1B7Y' where helix overrules sheet): helix > sheet > turn Q: What is the reasoning behind this priority list? Q: Shouldn't such faulty information rather be discarded? Regards, Rolf ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
