MantisBT - Rosetta
View Issue Details
0000295Rosetta[All Projects] Bad Codingpublic2013-08-06 18:292017-08-21 18:06
All platformsAnyAny
anything using sasa
0000295: core::scoring::sasa::calc_per_atom_sasa_sc divides by zero with NCAAs/Ligands
if you call calc_per_atom_sasa_sc with normalize=true, the function normalizing_area is called. normalizing_area takes the name1 of the residuetype and uses the int value of the char to get a hardcoded value from a vector. The default value of the vector is 0.0, which means that a residue with a name1 other than one of the 20 canonical name1s will return 0.0, and divide the residue sasa by 0. The result of this in c++ is undefined and will result in a random number for the normalized sasa.

I suspect that the area lookup table was implemented as a vector for speed reasons, however the current behavior is extremely dangerous and would result in very difficult to diagnose bugs. The only reason I found it at all is because I was carefully reading for another purpose. Replacing this vector with a map, hash table, or something else would address the error.

additionally, while ligands typically have a name1 of X, this is not a requirement, and thus you cannot know that a ligand with a name1 of A is actually alanine. The failure mode of this code due to strange user input is not an error but rather a potentially subtle incorrect sasa calculation of the residue. the datastructure should almost certainly be indexed by the full name of the residuetype, as a patched residuetype can maintain the same name1 or name3 and have a very different chemical composition than the canonical AA.

No tags attached.
Issue History
2013-08-06 18:29delucaslNew Issue
2013-08-06 18:34delucaslNote Added: 0000310
2013-08-06 18:34delucaslSeveritymajor => minor
2017-08-21 18:06amw579Fixed in SVN Version => n/a
2017-08-21 18:06amw579Statusnew => closed
2017-08-21 18:06amw579Assigned To => amw579
2017-08-21 18:06amw579Resolutionopen => suspended

2013-08-06 18:34   
Changing status to minor. This is only currently used in core/scoring/methods/ProQ_Energy, which uses it in such a limited case that its unlikely that the bug occurs in practice. However, future use of this code outside of the originally intended scope will be subject to the bug