Opened 7 years ago
Closed 7 years ago
#1365 closed defect (fixed)
Bad geometry can crash graphics on ribbon generation
Reported by: | Tristan Croll | Owned by: | pett |
---|---|---|---|
Priority: | moderate | Milestone: | |
Component: | Graphics | Version: | |
Keywords: | Cc: | Tom Goddard, Conrad Huang | |
Blocked By: | Blocking: | ||
Notify when closed: | Platform: | all | |
Project: | ChimeraX |
Description (last modified by )
Arising out of working through CASP assessments... one model had a residue (the first, but I don't think that should actually make a difference) in which all the coordinates were zero. This crashes dssp and, by extension, the whole graphics loop on generating the cartoon when first loading the model.
I think the _create_ribbon_graphics code needs to catch the ValueError coming out of get_polymer_spline and do something intelligent, e.g. stopping the ribbon
Attachments (1)
Change History (5)
comment:1 by , 7 years ago
Cc: | added |
---|---|
Owner: | changed from | to
comment:2 by , 7 years ago
Cc: | added; removed |
---|---|
Owner: | changed from | to
by , 7 years ago
1gcn with no headers and first residue coords zeroed out
comment:3 by , 7 years ago
Owner: | changed from | to
---|
Ultimately, the ribbon spline code asks for the ribbon orientation of a residue, which depends on its secondary structure type, and triggers a call to structure()->compute_secondary_structure();
in Residue::ss_type()
. compute_secondary_structure
should catch the normalization error and assign "TURN" for either the bad residue or all residues. The ribbon display code may still choke on the bad coordinates, but that will be in a different section of code.
comment:4 by , 7 years ago
Cc: | added; removed |
---|---|
Description: | modified (diff) |
Resolution: | → fixed |
Status: | assigned → closed |
Instead of throwing an error out of the dssp code, it _logs_ an error (which brings up an error dialog with an actual informative error message) but otherwise keeps going -- assigning all turn to the structure and allowing the ribbon code to function.
Okay, assigning this back to Conrad. Testing with a 1gcn with all headers removed and the coordinates of the first residue zeroed out (attached), the crash occurs in the ribbon code, not the dssp code, as per this traceback: