Re: [Cdk-devel] Proposed changes to the SDG

[<a.s...@ch...>]

Yes, I think this is the way to go.

Right now most tests only check whether an exception or a time out 
occurs. Many tests also check whether all atoms have Point2ds set, but 
this is of course always the case since the SDG fixes all atoms with 
null Point2ds after having done the layout.

How would such an algorithmically testing of the layout look like?

cheers,
Andreas

richard apodaca wrote:
> Sorry if this has already been answered, but what does
> the SDG testing code consist of? Chris and I were
> throwing around ideas for an SDG testing fixture. That
> way, any changes to the SDG code could be run against
> a collection of a few thousand molecules to verify
> algorithmically that everything still works as
> expected.
> 
> cheers,
> Rich
> 
> --- Andreas Schüller
> <a.s...@ch...> wrote:
> 
>> Hey Christoph,
>>
>> I've just committed a larger set of changes to the
>> SDG.
>>
>> Mainly, this is what happend:
>>
>> Changed the way templates are handled. Now, at the
>> beginning,
>> substructures matching templates are collected but
>> no coordinates are
>> assigned. Then when layoutRingSet() is called it is
>> checked whether the
>> ring set to lay out is part of a mapped
>> substructure. Before the 
>> changes, this wasn't possible since
>> RingPartitioner.partitionRings(sssr) 
>> separates all rings and the template handler could
>> not match the 
>> templates anymore.
>>
>> The cause for hard to reproduce
>> StructureDiagramGenerator bugs was the
>> undeterministic order of the rings returned by
>> SSSRFinder.findSSSR(). 
>> The rings are now sorted by a new method 
>> AtomContainerSetManipulator.sort() which uses the
>> new class 
>> AtomContainerComparator.
>>
>> Also the safetyCounters in the SDG were made
>> effective. This should
>> prevent all hangs of the SDG in future.
>>
>> The commit fixes bugs #1784850, #1677912 and
>> #1714794. In fact no SDG 
>> test fails right now.
>>
>> There are still problems with the layout of
>> structures containing 
>> mappable templates. I'll submit one example as a bug
>> report. But at 
>> least now it's possible to have nicely laid out
>> structures with more 
>> than one mapped template and all hangs should be
>> definitely gone.
>>
>> cheers,
>> Andreas
>>
>> Christoph Steinbeck wrote:
>>> Andreas,
>>>
>>> thanks so much for the detailed analysis.
>>> This is incredibly helpful.
>>> I have no objections against your commits.
>>>
>>> Regarding SSSRFinder: Since it now uses a Minimum
>> Cycle Base Algorithm,
>>> at least the ring set should be canonical. This
>> does, of course, no
>>> imply a canonical order. What I'm trying to say
>> is: Adding a canonical
>>> order on top of a canonical ring set should bring
>> us nearer to a
>>> deterministic layout.
>>>
>>> Your suggest ordering algorithm based on simple
>> counts is likely to be
>>> faster that my first thought of making a canonical
>> smiles for each ring
>>> (these rings tend to be small and so that will be
>> reasonably fast) and
>>> then use a lexicographic order on the smiles.
>>>
>>> Please go ahead: I'll run my NCI database layout
>> on your submission to
>>> see if things improve.
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>>
>>> Andreas Schüller wrote:
>>>> Hey all,
>>>>
>>>> while working on bug #1784850 "SDG hangs in
>> infinite loop"
> http://sourceforge.net/tracker/index.php?func=detail&aid=1784850&group_id=20024&atid=120024
>>>> I once more noticed, that the
>> StructureDiagramGenerator somehow doesn't 
>>>> work deterministically.
>>>>
>>>> I noticed some strange effects like that a
>> molecule would be rendered 
>>>> with ugly overlaps in normal execution mode but
>> nicely in debug mode. 
>>>> Also the infinite loop of the bug does not occur
>> when I run the CDK test 
>>>> case I wrote, but does occur in my Java
>> application.
>>>> I finally realised that this behaviour is due to
>> SSSRFinder.findSSSR() 
>>>> returning rings in an undeterministic order.
>>>>
>>>> Hence, I suggest to sort the rings returned by
>> SSSRFinder.findSSSR(). 
>>>> This will cause only a very little overhead but
>> the big benefit are 
>>>> reproducible results of the SDG.
>>>>
>>>> For this task I've added a method
>> sort(IAtomContainerSet 
>>>> atomContainerSet) to 
>>>>
> org.openscience.cdk.tools.manipulators.AtomContainerSetManipulator
>> and 
>>>> have placed an AtomContainerComparator into 
>>>> org.openscience.cdk.tools.manipulators which
>> compares IAtomContainers 
>>>> for order with the following criteria with
>> decreasing priority:
>>>>     * Compare atom count
>>>>     * Compare molecular weight (heavy atoms only)
>>>>     * Compare bond count
>>>>     * Compare sum of bond orders (heavy atoms
>> only)
>>>> If no difference can be found with the above
>> criteria, the 
>>>> AtomContainers are considered equal.
>>>>
>>>> If there are no objections I'll go ahead and
>> commit the changes.
>>>> Andreas
>>>>
>>>>
>>>> P.S. Since I need to add a new class to CDK do I
>> need to fiddle around 
>>>> with the SVN java doc header? Or does SVN create
>> it for me?
>>>
>>
> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? 
>> Stop.
>> Now Search log events and configuration files using
>> AJAX and a browser.
>> Download your FREE copy of Splunk now >> 
>> http://get.splunk.com/
>> _______________________________________________
>> Cdk-devel mailing list
>> Cdk...@li...
>>
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
> 
> 
> ____________________________
> Richard Apodaca
> Blog: http://depth-first.com
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Cdk-devel mailing list
> Cdk...@li...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
> 

-- 
Andreas Schüller
PhD student in the research group of Prof. Dr. Gisbert Schneider

Johann Wolfgang Goethe University
Beilstein-endowed Chair for Chemoinformatics
Building B - 3rd floor
Siesmayerstr. 70
60323 Frankfurt am Main
Germany

Tel.: +49 69 798 24879
Fax: +49 69 798 24880
http://www.modlab.de/