Hi, This mail turned out longer than I had expected. Some parts should probably be in the docs so I'll copy them :-) My main question is: Should I try to fix the recent SSSR bug (see link at the bottom).
Is anyone familiar with the SSSR code? Geoff's name is in the file but I don't know if there have been many ring perception bugs in the past. There is a recent bug report where not all SSSR rings are found. We have a DetermineFRJ which should give the correct number of SSSR rings. The missing ring in the first structure should be found (4x 3 rings, 1x 4 ring). FRJ = m - n + 1 = 16 - 12 + 1 = 5 (This is frère jacques number or Cauchy formula. Or even Euler's formula from which it was derived. This is the rule the bug report refers to) Only 4 are found, I haven't confirmed this but the report seems descent. Unless Geoff wants to try first, I can have a look to see what is wrong with the first structure. The second structure in the report contains a large ring, we seem to have a maximum ring size of 20 (or 40 with two paths, I only see one but don't know the code well). Was this limit ever updated? We could make this a setting though. Currently it is hard coded using a define: src/ring.cpp:523: #define OB_RTREE_CUTOFF 20 For the second structure, some performance tests are probably the best way to evaluate the max ring size. The current code is fast in determining ring membership (O(n)). With this information, a large but otherwise simple ring should be found in a fraction of a millisecond. For another project, I'm also planning to use the SSSR as a minimal cycle basis to generate a canonical ring set. See http://imagebin.org/101901 for examples or think about bridged rings and platonic solids (tetrahedron, cube, ...) where one ring is missing (all atoms and bonds of thos missing ring are part of other rings). Once I get it to work, adding this to OB should be easy. This would fix a bug in the MMFF94 atom typing and makes queries using atom ring count (i.e. R<n> in SMARTS) behave more intuitive for (computational) chemists. To be correct, it is just wrong to use the SSSR for R in smarts since finding a match might depend on atom order. This is how daylight still specifies it though. Bug report: http://sourceforge.net/tracker/?func=detail&atid=428740&aid=3017553&group_id=40728 Cheers, Tim ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
