Opened 8 years ago
Closed 4 years ago
#1021 closed enhancement (fixed)
Compute auxiliary secondary structure info
| Reported by: | Eric Pettersen | Owned by: | Eric Pettersen |
|---|---|---|---|
| Priority: | moderate | Milestone: | 1.4 |
| Component: | Core | Version: | |
| Keywords: | Cc: | Greg Couch | |
| Blocked By: | Blocking: | ||
| Notify when closed: | Platform: | all | |
| Project: | ChimeraX |
Description (last modified by )
on demand
Change History (5)
comment:1 by , 7 years ago
| Description: | modified (diff) |
|---|---|
| Priority: | blocker → moderate |
comment:2 by , 5 years ago
| Milestone: | → 1.3 |
|---|
comment:3 by , 4 years ago
| Milestone: | 1.3 → 1.4 |
|---|
comment:4 by , 4 years ago
| Cc: | added |
|---|---|
| Description: | modified (diff) |
| Summary: | First class secondary structure elements → Compute auxiliary secondary structure info |
Upon sober reflection, I've decided that having Helix, Sheet, etc. classes is far more trouble than it's worth. Right now its easy for a user to combine two strands separated by straight coil into one strand by reassigning ss_types and ss_ids. As classes, that would be a nightmare. And what about coordinate sets? Ouch.
Instead, have a dssp-like routine that computes the auxiliary secondary structure info on request, for the infrequent cases where it is needed.
comment:5 by , 4 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
This actually got implemented 9 months ago (ss_info arg to AtomicStructure::compute_secondary_structure())
Possible intermediate state would be for AtomicStructure::compute_secondary_structure() to optionally save the report in a Python data structure. Then the mmCIF writer could use that information to write out correct sheet information, instead of having each strand in its own sheet.