cdk-user — Post your questions on the use of the binaries.

[Cdk-user] Fwd: Re: thanks. making slow progress but steady. RE: CDK questions - reading in SMILES and then laying the structures out 2D.

[Egon W. <e.w...@sc...>]

----------  Forwarded Message  ----------

Subject: Re: thanks.  making slow progress but steady.  RE: CDK questions - 
reading in SMILES and then laying the structures out 2D.
Date: Thursday 10 February 2005 16:30
From: Egon Willighagen <e.w...@sc...>
To: "Juergen Harter" <Jue...@bi...>

On Thursday 10 February 2005 04:20 pm, Juergen Harter wrote:
> just managed to successfully read in cathine.smi with the SMILESReader.
> I'll deal with the iterations later. Could you perhaps point me to the
> JChemPaint classes that deal with reading in SMILES strings so I can
> educate myself further.

See org.openscience.jchempaint.dialogs.InsertFromSmiles.

> I shall investigate the
> cdk.io.iterator.IteratingSMILESReader you mentioned. thanks.
>
> > Ah, good, you already found the MoleculeViewer2D class :)
>
> I have found that class, but I don't know how to embedd that properly into
> a JFrame.
> Can you give me a hint or just a few lines of code for that?

Have a look at:

http://cvs.sourceforge.net/viewcvs.py/cdk/cdk/src/org/openscience/cdk/applications/Attic/Viewer.java?rev=1.30&view=markup

> What I have is this now:
> // this section now will deals with displaying the molecule
> MoleculeViewer2D mv2d = new MoleculeViewer2D();
> mv2d.display(Molecule mol);

See the above Viewer.java, but it should look stomething like:

JFrame frame = new JFrame("CDK Molecule Viewer");
frame.getContentPane().setLayout(new BorderLayout());
MoleculeViewer2D mv = new MoleculeViewer2D(m);
frame.getContentPane().add(mv, BorderLayout.CENTER);
frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
frame.setSize(500, 500);
frame.setVisible(true);
frame.show();

> > >   mv2d.display(Molecule mol);    // need to find out how to
> > > display a single molecule!
> > >   BitSet bs = Fingerprinter.getFingerprint(mol);   // throws
> > > an exception so far ????
> >
> > Does it indeed throw an exception? What does it throw?
>
> Can't remember or reproduce it just yet, got other errors I'm battling with
> now. But I'll let you know via the list if it's CDK relevant for the
> general readership.

Ok.

> > >   System.out.println("Bitset is:"+bs);
> > >   Molecule frag1 = MoleculeFactory.makePyrrole();
> > >   BitSet bs1 = Fingerprinter.getFingerprint(frag1);
> > >   if (Fingerprinter.isSubset(bs, bs1)) {
> > >    System.out.println("Pyrrole is subset of Indole.");
> > > // this if clause is not correct yet.
>
> not sure about my if clause here, is the syntax corret actually? I seem to
> be getting a syntactic error message here. any comments on usage of if
> clauses appreciated.

Looks fine...

> > Looks good. Not much to improve on...
>
> cheers Egon, I think I have a bit to go through. But I am getting there, no
> doubt. Thanks for you help. Always much appreciated.

You're welcome :)

Egon

-------------------------------------------------------

-- 
e.w...@sc...
PhD student on Molecular Representation in Chemometrics
Radboud University Nijmegen
http://www.cac.science.ru.nl/people/egonw/
GPG: 1024D/D6336BA6

[Cdk-user] Fwd: Re: CDK questions - reading in SMILES and then laying the structures out 2D.

[Egon W. <e.w...@sc...>]

----------  Forwarded Message  ----------

Subject: Re: CDK questions - reading in SMILES and then laying the structures 
out 2D.
Date: Thursday 10 February 2005 15:11
From: Egon Willighagen <e.w...@sc...>
To: "Juergen Harter" <Jue...@bi...>
Cc: "Egon Willighagen (E-mail)" <eg...@sc...>

On Thursday 10 February 2005 02:15 pm, Juergen Harter wrote:
> Can I ask you a few things on CDK, and how to use some of it's classes?

Sure.

> Hope you can point me a bit more in the right direction.
> Cheers for the fix the other day with the dotted smiles. I guess it's
> better than it was before, although like you say, not quite fully right
> either, as I think salts should be displayed in one JChemPaint window. (I
> realise it may be far more complex to implement this correctly.)

Yes, I know... but JCP can't do that right now...

> By the
> way, I've got a few more SMILES issues/bugs which I'll be happy to post
> soon on Sourceforge.

Yes, please do.

> back to my cdk issues:
>
> Please find below a rough and first sketch of what I'd like to achieve:
> a) read in a list of smiles (up to 200), perhaps initially only starting
> with one for testing
> b) convert them into molecules and hold them in the CDK data structure
> c) lay them out and generate all 2D coordinates when necessary (probably
> always, as it's smiles input)
> d) do fingerprint calculations on all of them and store those in a matrix
> e) make some attempts at clustering those molecules either on similarity
> (Tanimoto), or perhaps with SMARTS substructures
>
> Now d) and e) is for much later, once I've achieved the simpler a-c
>

:)

> I would appreciate very much if you could look through the below java file
> displayMols2D.java and insert some of your expert CDK comments.
> I am very happy to invest some time and rewrite it more accurately, I just
> want to make sure that I am on the right track with the right sort of
> classes and methods I am wanting to use. Do point it out to me if there is
> a far better way of achieving what I described in a-b. And feel free to
> insert some code snippets off the top of your head into below code. Don't
> spend to much time on it, I shall rework it with your comments next, and
> then we can have another email exchange to get it running completely. I'll
> spend some time on the debugging once you've pointed me in the right
> directions. 

Ok.

> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>+ ++++++++++++++++++
> import org.openscience.cdk.templates.MoleculeFactory;
> import org.openscience.cdk.fingerprint.*;
> import org.openscience.cdk.*;

import org.openscience.cdk.io.*; // for the SMILESReader

> import java.util.BitSet;
> import javax.swing.JPanel;
> // which other imports do I need?
>
> /**
>  * This file is used to read in molecules given as smiles strings and then
> display them in 2D
>  * (with the 2DLayout)
>  *
>  * @author  Dr. Juergen Harter <jue...@bi...>
>  * @created  2005-02-10
>  *
>  */
>
>  public class displayMols2D {
>  /**
>   *  The main program for the displayMols2D class
>   *
>   *@param  args  The command line arguments - none required at this
> stage
>   */
>  public static void main(String[] args)  {
>
>   // need to find a way to read in 80 (or X) smiles from
> individual files
>   // how do I iterate through those, and where to I best read
> them into???

Why not put them all in one file? Use the SMILESReader. One SMILES on
each line.

>   // do we have an iterating SMILES reader, like the iterating
> MDLReader, if not, maybe I can write one?

Yes, cdk.io.iterator.IteratingSMILESReader

>   // for now, testing just with one:
>
>   try {
>
>   SMILESReader reader = new SMILESReader(new FileReader(new
> File("Cathine.smi")
>   // the molecule Cathine is:  CC(N)C(O)c1ccccc1
>
>   // convert the file here  (as done in CDK news Vol. 1/2
> November 2004, section on Properties Listener)
>
>   ChemFile content = (ChemFile)reader.read(new ChemFile());
>   Molecule molecule =
> content.getChemSequence(0).getChemModel(0).getSetOfMolecules().getMolecule(
>0 );
>   writer.write(molecule);  // how do I create a writer here,
> and what's written out anyway, to where??
>   writer.close();      // maybe I don't need writer, as
> I am continuing to process the molecule further down

Why do you want to write it? I don't think you need it...

>   } catch (Exception e)  {e.printStackTrace();}
>  }
>
>
> // this section here now needs to layout all the read in molecules in 2D:
>
> StructureDiagramGenerator sdg = new StructureDiagramGenerator();  //
> correct way of laying out molecules in a window??
>  sdg.setMolecule(molecule);
>  sdg.generateCoordinates();
>  Molecule layedOutMol = sdg.getMolecule();
> // where does this then display at all? which other
> classes/methods/constructurs do I need here

It doesn't display :) It only created 2D coords...

For viewing, have a look at cdk.applications.swing.MoleculeViewer2D
and embed that in a JFrame.

> // the goal is to display all the given molecule (for starters just one,
> Cathine), on screen
>
> // this section now will deal with identifying substructures and fragments:
>
>   System.out.println("Testing here for fingerprint generation
> for each of the read in molecules from above.");
>   System.out.println("Purpose: this class tests the
> fingerprinter and finds a fragment in a molecule.");
>   // need to iterate through the list of molecules (from 1-80)
> and generate fingerprints for each
>   // here first test the fingerprinting part with an example
> Indole:
>   Molecule mol = MoleculeFactory.makeIndole();
>   MoleculeViewer2D mv2d = new MoleculeViewer2D();

Ah, good, you already found the MoleculeViewer2D class :)

>   mv2d.display(Molecule mol);    // need to find out how to
> display a single molecule!
>   BitSet bs = Fingerprinter.getFingerprint(mol);   // throws
> an exception so far ????

Does it indeed throw an exception? What does it throw?

>   System.out.println("Bitset is:"+bs);
>   Molecule frag1 = MoleculeFactory.makePyrrole();
>   BitSet bs1 = Fingerprinter.getFingerprint(frag1);
>   if (Fingerprinter.isSubset(bs, bs1)) {
>    System.out.println("Pyrrole is subset of Indole.");
> // this if clause is not correct yet.
>    }
>
> }
> }
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>+ ++++++++++++++++++++

Looks good. Not much to improve on...

Egon

-------------------------------------------------------

-- 
e.w...@sc...
PhD student on Molecular Representation in Chemometrics
Radboud University Nijmegen
http://www.cac.science.ru.nl/people/egonw/
GPG: 1024D/D6336BA6

Re: [Cdk-user] Energy minimize molecule

[Christoph S. <c.s...@un...>]

Martin Eklund wrote:
> Hi,
> 
> I'm wondering about the status of the forcefield. As I understand things
> no potential function is yet implemented (only an interface for one). Is
> this in the pipe line? Or is the idea that you provide your own
> potential function?

Hi Martin,

there should be some serious advancements these days. As soon as I'm 
back in the office from my lenghty three week trip, I'll check the 
status and give an update.

Cheers,

Chris

-- 
Priv. Doz. Dr. Christoph Steinbeck (c.s...@un...)
Head of the Junior Research Group for Applied Bioinformatics
Cologne University BioInformatics Center (http://www.cubic.uni-koeln.de)
Zülpicher Str. 47, 50674 Cologne
Tel: +49(0)221-470-7426   Fax: +49 (0) 221-470-7786

What is man but that lofty spirit - that sense of enterprise.
... Kirk, "I, Mudd," stardate 4513.3..

[Cdk-user] Energy minimize molecule

[Martin E. <mar...@fa...>]

Hi,

I'm wondering about the status of the forcefield. As I understand things
no potential function is yet implemented (only an interface for one). Is
this in the pipe line? Or is the idea that you provide your own
potential function?

Cheers!

Martin.
  
-- 
========================================
Martin Eklund
PhD Student
Department of Pharmaceutical Biosciences
Uppsala University, Sweden
Ph: +46-18-4714281
========================================

[Cdk-user] PMD status

[Egon W. <e.w...@sc...>]

Hi all,

today PMD 2.2 was released, and we still used 1.8 so I took the opportunity to 
do an upgrade... in one go, I also added some new tests, leading to these
results for CVS [1]:

data                       67 errors (previously clean!)
core                        6 errors
standard                  269
io                        252
extra                    1847
render                     51
applications              190
libio                      14
experimental              224
builder3d                 139
test                      295

So if you ever wondered what to do when there's nothing on TV... :)

Many tests are really easy to fix, like removal of unused code, local and 
private fields, duplicate and unused imports. So, if you want to learn about
the CDK source code, such source code problems would be an excellent place to
start, and *much* appreciated by the core developers.

Egon

1. http://cdk.sf.net/reports/pmd/

[Cdk-user] Some more notes on the UniversalIsomorphismTester class

[Irilenia N. <no...@eb...>]

Hi all,

I thought the following summary of my e-mail exchanges with the author of
the UniversalIsomorphismTester class might be of interest to users of this
class.

The main points were the following:

a) Thierry agrees that there is a bug in the getIsomorphMap() method of
this class.
Instead of the following call to the search() method:

List rMapsList = search(g1, g2, getBitSet(g1),
        getBitSet(g1), false, false);

the call should be:

List rMapsList = search(g1, g2, getBitSet(g1),
        getBitSet(g2), false, false);

This is also true of the corresponding call in the getIsomorphMaps()
method.

b) I thought that  the isIsomorph() method should test initially for the
presence of isomorphism simply by comparing the number of nodes and edges
in the two graphs, and excluding any cases where the two graphs are of
different size. Thierry suggests that this test be part instead of a
higher-level method calling the isIsomorph() method. His actual response
was:

>Yes that is true, however this algorithm is not intended to solve
>optimization aspects. It is assumed that
>their should be a set of filters prior to getting to the point of using
>this method. Typically the test
>you suggest would be such a filter. The set of method provided in the
>Isomorphism toolkit is a very
>low level API that is provided to build some more sophisticated access
>on top of it.

This is fine, but people should be aware of it: they should use their own
filters before calling this method. This means that perhaps the
getOverlaps() method should do this, as this is clearly a higher level
method, despite the fact that it is included in the same class.

c) Regarding a clarification on what exactly the getOverlaps() method is
supposed to be returning: It returns ALL CONNECTED maximum common
substructures between two graphs. These substructures are maximum in the
sense that it is not possible to extend them - their actual size is
irrelevant, which is why more than one are often returned. In Thierry's
own words:

>As you mention, some definition of the MCSS are based on the size of the
>resulting common substructure and
>the corresponding algorithms generally  lead to the largest MCSS in
>terms of size.. The reason is mainly
>because it is easier and/or faster to search for only one MCSS and
>further more it is usually convenient to
> expect a single structure from the caller point of view.
>In many applications of MCSS search you would preferre to get only one
>overlapping structure, so
>it it easier to go further in your investigation with this single result
>(e.g. take it as a scaffold and so on...)
> However when we started our algorithm design  we beleived (and still
>strongly beleive)
> that the term 'maximum' in MCSS should not be related to the size of
>the structure but only to
>the ability or not to find a common structure that would extend the
>considered solution. Thus in our definition of MCSS
>the M (maximum) stands for 'maximum possible span' and not  largest size
>(in number of atoms/bonds).
>This rule enable more then one MCSS for the same couple of graphs.
>Choosing a 5 atom MCSS rather then a 2 atom MCSS has no chemical (or
>generally graph) meaning since
>both substructures represent a common feature between the two initial
>graphs and there is no
>reason that the 5 membered MCSS has more value as the 2 membered one.
>Therefore we decided that
>it is very important to keep and report  ALL  the 'DISTINCT' MCSS  in
>the result set. Only further contextual
>analysis may lead to a ranking of the MCSS found but there is no reason
>that the bigest structure
>wins over the others.
>The term 'DISTINCT' here means that for any couple s1, s2 belonging to
>the set of resulting MCSS,
>s1 and s2 are never isomorph nor substructure from one another.

 
d) The fact that we have cases where the order that the two graphs are
passed onto the getOverlaps() method dictates the maximum common
substructures returned must be due to a bug, but none of us knows yet
where this bug lies.

e) There will hopefully be a publication in English in the not so far
future explaining fully the algorithm used in this class, so that people
using it can cite it properly.

f) Finally, sometime ago I asked Thierry about another problem with this
class, but never got around to copy my question and his answer to the
list. The problem was described by me as follows:
>>>
It seems that when the class was written, because it matched bonds and not
atoms, it had a problem dealing with one-atom molecules that matched one
atom in another molecule. Someone attempted to correct this by adding some
code in the "search" function which checks whether there is only one atom
in either molecule. However, when it finds the mapping of that one atom,
it adds the corresponding RMap onto an ArrayList and returns this
ArrayList. This does
not seem to be consistent with the fact that if the molecules both have
more than one atom and hence the original code is executed what is
returned is a List of Lists of RMaps. The problem only becomes apparent
once the returned List is passed on to another function which expects not
a List of RMaps but a List of Lists of RMaps (see the projectList function
for example being called inside the getOverlaps function: once the search
is performed and the List is returned, it becomes a parameter to
projectList(). But projectList() treats this as a List of Lists - if you
give it a List of RMaps it raises a class cast Exception).
<<<
Thierry's answer to this was:
> Back from UK I had a look at your bug report and I agree with you. The
> changes introduced by shk3 in version 1.23 of the
> UniversalIsomorphismTester are not consistent with the search() method's
> primary goal. This method is supposed to return the List of solutions,
> each solution being itself a List of b ond "mappings". The algorithm was
> not designed to handle single atom cases which sould be treated outside
> the RTools framework (e.g. using a case filtering prior to using this
> MCSS facilties).
>
> As far as I could see from the code, their seem to be actually two
> inconsistency:
>
> 1. - When dealing with single atom containers, the search method returns
> an atom mapping oriented solution
>     on the other hand, when dealing with multi-atom containers, the
> search returns the expected bond oriented mapping solutions
>
> 2. The structure of the result is different in each case. Single List in
> the first case, List of List in the second (the latter is correct).
>
> Hence, the behaviour has become quite odd since the meening and the
> structure of the returned object depends on the context. two possible
> solutions :
> *  take the special single atom case filter outside the search method
> and provide a single atom case searcher
>
> or
> *  convert the whole isomorphisme framework to deal with atom Mappings
> (e.g. by eventually converting the bond maps into atom maps before
> returning the solutions (but still, the List of solution should be a
> list of mappings,  even if there is a single atom to atom map it should
> still be in a singleton List its self belonging to the list of solutions
> (in this case also a singleton List) : search() --> {{ (atom in G1/ atom
> in G2) }}  and not { (atom in G1/ atom in G2) }  as it is now.
>
> Unless I missunderstood the new code, I think the code has to be fixed.


Hope this will be of help to users of this class, and perhaps some of the 
problems can be solved for future releases.

Many thanks to Thierry for his remarks and help.

Irilenia

++++++++++++++++++++++++++++++++++++++++ 
Irilenia (Irene) Nobeli 
EMBL - European Bioinformatics Institute
Wellcome Genome Campus
Hinxton
Cambridge CB10 1SD
tel: +44 (0) 1223 492550
fax: +44 (0) 1223 494468
e-mail: no...@eb...

Re: [Cdk-user] Possible solution to graph matching problem?

[Egon W. <eg...@us...>]

Irilenia/All, =A0

On Wednesday 26 January 2005 12:20, Irilenia Nobeli wrote:
> I think I may have found the cause of the graph matching problem I
> mentioned recently.
> The getOverlaps() method of UniversalIsomorphismTester works as follows:
> a)It does a search for all possible mappings
> b)It projects the solutions on the first molecule
> c)It reduces the solutions by checking for possible subgraphs or
> isomorphic graphs.
>
> The problem is I think in part (c). The series of calls to methods is
> as follows:
>
> getOverlaps() -> getMaximum() -> isIsomorph() -> getIsomorphMap()
> ->search()
>
> I think the problem is the way the search method is called:
> List rMapsList =3D search(g1, g2, getBitSet(g1),
>         getBitSet(g1), false, false);
> (line 140 in UniversalIsomorphismTester.java)
>
> Shouldn't that be:
> List rMapsList =3D search(g1, g2, getBitSet(g1),
>         getBitSet(g2), false, false);
>
> so that all bonds in BOTH graphs must be matched? Isn't this the
> definition of isomorphic graphs?
>
> Hope this is of some help towards solving the problem for the next
> release.
=A0
about your possible solution, I've another occurence of this way of=20
calling the search() method (rev 1.29):=20
=2D on line 140 is the line you mentioned=20
=2D on line 172 is another call like thus=20
=A0
But, the JavaDoc of the search method says:=20
=A0 /**=20
=A0 =A0* =A0General Rgraph parsing method (usually not used directly)=20
=A0 =A0* =A0This method is the entry point for the recursive search=20
=A0 =A0* =A0adapted to the atom container input.=20
=A0 =A0*=20
=A0 =A0* @param =A0g1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0first molecule=20
=A0 =A0* @param =A0g2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0second molecule=20
=A0 =A0* @param =A0c1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0initial condition ( bo=
nds from g1 that=20
=A0 =A0* =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 must be contai=
ns in the solution )=20
=A0 =A0* @param =A0c2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0initial condition ( bo=
nds from g2 that=20
=A0 =A0* =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 must be contai=
ns in the solution )=20
=A0 =A0* @param =A0findAllStructure =A0if false stop at the first structure=
 found=20
=A0 =A0* @param =A0findAllMap =A0 =A0 =A0 =A0if true search all the 'mappin=
gs' for one=20
same=20
=A0 =A0* =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 structure=20
=A0 =A0* @return =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a list of rMapList tha=
t represent the search=20
solutions=20
=A0 =A0*/=20
=A0 public static List search(AtomContainer g1, AtomContainer g2, BitSet=20
c1,=20
=A0 =A0 =A0 BitSet c2, boolean findAllStructure, boolean findAllMap) {=20
=A0
=2E.. suggesting that you might be right.=20
=A0
So, question: is the code broken at two places, or is the JavaDoc=20
not clear on the subject?=20
=A0
Modifying the two methods given above does not break any JUnit test=20
but does not fix this bug either...=20
=A0
See:=20
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1110537&group_=
id=3D20024&atid=3D120024

thoughts?=20
=A0
Egon=20


> > Date: Tue, 25 Jan 2005 18:05:40 +0000 (GMT)
> > From: Irilenia Nobeli <no...@eb...>
> > To: cdk...@li...
> > Subject: [Cdk-user] Graph matching problem
> >
> > Hi,
> >
> > I have noticed that there are cases where the graph matching algorithm
> > seems to return different results for a pair of molecules depending on
> > the order these molecules are passed onto the method getOverlaps of the
> > class UniversalIsomorphismTester. I don't mean that the mappings are
> > different (which they should be as they are projections always on the
> > first molecule) but that the maximum common structure returned has a
> > different size. I may be wrong, but this looks like a bug.
> >
> > For example, take the two molecules attached as MDL files. If you run
> > UniversalIsomorphismTester.getOverlaps(mol1, mol2) on these two, in
> > one case
> > you get a clique of 2 atoms, in the other a clique of 11 atoms. These t=
wo
> > molecules both have hydrogens in the original file. If the hydrogens are
> > removed, you get mappings with the same number of atoms, regardless of
> > which molecule is first and which is second, i.e. the problem is not
> > there anymore (actually there could be other examples where even after
> > removal of hydrogens the problem remains - I just haven't come across
> > them yet).
> >
> > Well, if anyone has any ideas why this happens, I could do with some
> > help.
> >
> > Thanks,
> >
> > Irilenia

=2D-=20
eg...@us...
GPG: 1024D/D6336BA6

[Cdk-user] More bugs in graph matching

[Irilenia N. <no...@eb...>]

Hi again,

Well, as I found out even if the call to the search method is properly
done (as suggested in my previous e-mail), it is not guaranteed that the
maximum common substructure will be
the same regardless of the order of the atom containers passed as
arguments to the getOverlaps() method of the UniversalIsomorphismTester
class. 

I suspect this is a bug in the actual implementation of the search
algorithm (which at the moment I'm not familiar with). An example are the
molecules attached (5SD.sdf and HYC.sdf). If 5SD is given first, the
algorithm finds a substructure of 20 atoms (among other smaller ones) that
is shared by both molecules
(removing the hydrogens from both molecules before passing them onto the
getOverlaps() method!). If HYC is given first, the biggest substructure
returned has 19 atoms. So the algorithm has not found the largest
substructure in this case.

For anyone interested the largest substructure (20 atoms) found by this
method and mapped onto the two molecules is attached as files map_5SD.sdf
and map_HYC.sdf.

I.


> 
> Message: 2
> Date: Wed, 26 Jan 2005 11:20:30 +0000 (GMT)
> From: Irilenia Nobeli <no...@eb...>
> To: cdk...@li...
> Subject: [Cdk-user] Possible solution to graph matching problem?
> 
> 
> I think I may have found the cause of the graph matching problem I
> mentioned recently. 
> The getOverlaps() method of UniversalIsomorphismTester works as follows:
> a)It does a search for all possible mappings
> b)It projects the solutions on the first molecule
> c)It reduces the solutions by checking for possible subgraphs or
> isomorphic graphs.
> 
> The problem is I think in part (c). The series of calls to methods is
> as follows:
> 
> getOverlaps() -> getMaximum() -> isIsomorph() -> getIsomorphMap()
> ->search()
> 
> I think the problem is the way the search method is called:
> List rMapsList = search(g1, g2, getBitSet(g1),
>         getBitSet(g1), false, false);
> (line 140 in UniversalIsomorphismTester.java)
> 
> Shouldn't that be:
> List rMapsList = search(g1, g2, getBitSet(g1),
>         getBitSet(g2), false, false);
> 
> so that all bonds in BOTH graphs must be matched? Isn't this the
> definition of isomorphic graphs?
> 
> Hope this is of some help towards solving the problem for the next
> release.
> 
> I.
> 

++++++++++++++++++++++++++++++++++++++++
Irilenia (Irene) Nobeli
EMBL - European Bioinformatics Institute
Wellcome Genome Campus
Hinxton
Cambridge CB10 1SD
tel: +44 (0) 1223 492550
fax: +44 (0) 1223 494468
e-mail: no...@eb...

[Cdk-user] Possible solution to graph matching problem?

[Irilenia N. <no...@eb...>]

I think I may have found the cause of the graph matching problem I
mentioned recently. 
The getOverlaps() method of UniversalIsomorphismTester works as follows:
a)It does a search for all possible mappings
b)It projects the solutions on the first molecule
c)It reduces the solutions by checking for possible subgraphs or
isomorphic graphs.

The problem is I think in part (c). The series of calls to methods is
as follows:

getOverlaps() -> getMaximum() -> isIsomorph() -> getIsomorphMap()
->search()

I think the problem is the way the search method is called:
List rMapsList = search(g1, g2, getBitSet(g1),
        getBitSet(g1), false, false);
(line 140 in UniversalIsomorphismTester.java)

Shouldn't that be:
List rMapsList = search(g1, g2, getBitSet(g1),
        getBitSet(g2), false, false);

so that all bonds in BOTH graphs must be matched? Isn't this the
definition of isomorphic graphs?

Hope this is of some help towards solving the problem for the next
release.

I.

On Tue, 25 Jan 2005 cdk...@li... wrote:

> Send Cdk-user mailing list submissions to
> 	cdk...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/cdk-user
> or, via email, send a message with subject or body 'help' to
> 	cdk...@li...
> 
> You can reach the person managing the list at
> 	cdk...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cdk-user digest..."
> 
> 
> Today's Topics:
> 
>    1. Graph matching problem (Irilenia Nobeli)
> 
> --__--__--
> 
> Message: 1
> Date: Tue, 25 Jan 2005 18:05:40 +0000 (GMT)
> From: Irilenia Nobeli <no...@eb...>
> To: cdk...@li...
> Subject: [Cdk-user] Graph matching problem
> 
>   This message is in MIME format.  The first part should be readable text,
>   while the remaining parts are likely unreadable without MIME-aware tools.
>   Send mail to mi...@do... for more info.
> 
> --380388872-788217705-1106676340=:25814
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> 
> Hi,
> 
> I have noticed that there are cases where the graph matching algorithm
> seems to return different results for a pair of molecules depending on the
> order these molecules are passed onto the method getOverlaps of the class
> UniversalIsomorphismTester. I don't mean that the mappings are different
> (which they should be as they are projections always on the first
> molecule) but that the maximum common structure returned has a different
> size. I may be wrong, but this looks like a bug.
> 
> For example, take the two molecules attached as MDL files. If you run
> UniversalIsomorphismTester.getOverlaps(mol1, mol2) on these two, in
> one case
> you get a clique of 2 atoms, in the other a clique of 11 atoms. These two
> molecules both have hydrogens in the original file. If the hydrogens are
> removed, you get mappings with the same number of atoms, regardless of
> which molecule is first and which is second, i.e. the problem is not there
> anymore (actually there could be other examples where even after removal
> of hydrogens the problem remains - I just haven't come across them yet).
> 
> Well, if anyone has any ideas why this happens, I could do with some help.
> 
> Thanks,
> 
> Irilenia
> 
> ++++++++++++++++++++++++++++++++++++++++
> Irilenia (Irene) Nobeli
> EMBL - European Bioinformatics Institute
> Wellcome Genome Campus
> Hinxton
> Cambridge CB10 1SD
> tel: +44 (0) 1223 492550
> fax: +44 (0) 1223 494468
> e-mail: no...@eb...
> 
> --380388872-788217705-1106676340=:25814
> Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ADN.sdf"
> Content-Transfer-Encoding: BASE64
> Content-ID: <Pin...@gi...>
> Content-Description: 
> Content-Disposition: attachment; filename="ADN.sdf"
> 
> QURODQpJTnRjbHNlcnZlMDEyNDA1MTQ1NzJEIDAgICAwLjAwMDAwICAgICAw
> LjAwMDAwICAgIDQ3DQogDQogMzIgMzQgIDAgIDAgIDAgIDAgIDAgIDAgIDAg
> IDA5OTkgVjIwMDANCiAgICAyLjg2NjAgICAtMy4yMzc1ICAgIDAuMDAwMCBO
> ICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDIu
> ODY2MCAgIC0yLjIzNzUgICAgMC4wMDAwIEMgICAwICAwICAwICAwICAwICAw
> ICAwICAwICAwICAwICAwICAwDQogICAgMi4wMDAwICAgLTEuNzM3NSAgICAw
> LjAwMDAgTiAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAN
> CiAgICAyLjAwMDAgICAtMC43Mzc1ICAgIDAuMDAwMCBDICAgMCAgMCAgMCAg
> MCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDIuODY2MCAgIC0wLjIz
> NzUgICAgMC4wMDAwIE4gICAwICAwICAwICAwICAwICAwICAwICAwICAwICAw
> ICAwICAwDQogICAgMy43MzIxICAgLTAuNzM3NSAgICAwLjAwMDAgQyAgIDAg
> IDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICA0LjY3ODMg
> ICAtMC40MzI3ICAgIDAuMDAwMCBOICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAg
> MCAgMCAgMCAgMCAgMA0KICAgIDUuMjYxOSAgIC0xLjIzNzUgICAgMC4wMDAw
> IEMgICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwDQogICAg
> NC42NzgzICAgLTIuMDQyMiAgICAwLjAwMDAgTiAgIDAgIDAgIDAgIDAgIDAg
> IDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICAzLjczMjEgICAtMS43Mzc1ICAg
> IDAuMDAwMCBDICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAg
> MA0KICAgIDQuOTg4OSAgICAwLjUxNzggICAgMC4wMDAwIEMgICAwICAwICAy
> ICAwICAwICAwICAwICAwICAwICAwICAwICAwDQogICAgNC4zNzY0ICAgIDAu
> NDIxOSAgICAwLjAwMDAgSCAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAg
> IDAgIDAgIDANCiAgICA1Ljk0MDUgICAgMC44MjUyICAgIDAuMDAwMCBPICAg
> MCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDUuOTQy
> MyAgICAxLjgyNTIgICAgMC4wMDAwIEMgICAwICAwICAyICAwICAwICAwICAw
> ICAwICAwICAwICAwICAwDQogICAgNi40OTQyICAgIDEuNTQyNyAgICAwLjAw
> MDAgSCAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAg
> ICA2Ljc1MjMgICAgMi40MTE2ICAgIDAuMDAwMCBDICAgMCAgMCAgMCAgMCAg
> MCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDcuNjY1MSAgICAyLjAwMzIg
> ICAgMC4wMDAwIE8gICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAw
> ICAwDQogICAgNC45OTE3ICAgIDIuMTM1OCAgICAwLjAwMDAgQyAgIDAgIDAg
> IDEgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICA1LjQzMDkgICAg
> Mi41NzM1ICAgIDAuMDAwMCBIICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAg
> MCAgMCAgMCAgMA0KICAgIDQuNjg0NCAgICAzLjA4NzQgICAgMC4wMDAwIE8g
> ICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwDQogICAgNC40
> MDI1ICAgIDEuMzI3OCAgICAwLjAwMDAgQyAgIDAgIDAgIDEgIDAgIDAgIDAg
> IDAgIDAgIDAgIDAgIDAgIDANCiAgICA0LjEyMjAgICAgMS44ODA3ICAgIDAu
> MDAwMCBIICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0K
> ICAgIDMuNDAyNSAgICAxLjMyOTYgICAgMC4wMDAwIE8gICAwICAwICAwICAw
> ICAwICAwICAwICAwICAwICAwICAwICAwDQogICAgMi4zMjkxICAgLTMuNTQ3
> NSAgICAwLjAwMDAgSCAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAg
> IDAgIDANCiAgICAzLjQwMzAgICAtMy41NDc1ICAgIDAuMDAwMCBIICAgMCAg
> MCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDEuNDYzMSAg
> IC0wLjQyNzUgICAgMC4wMDAwIEggICAwICAwICAwICAwICAwICAwICAwICAw
> ICAwICAwICAwICAwDQogICAgNS44ODE5ICAgLTEuMjM3NSAgICAwLjAwMDAg
> SCAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICA3
> LjA5OTkgICAgMi45MjUwICAgIDAuMDAwMCBIICAgMCAgMCAgMCAgMCAgMCAg
> MCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDYuMzA3MCAgICAyLjg0MzAgICAg
> MC4wMDAwIEggICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAw
> DQogICAgOC4xNjczICAgIDIuMzY2OCAgICAwLjAwMDAgSCAgIDAgIDAgIDAg
> IDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICA1LjEwMDAgICAgMy41
> NDc1ICAgIDAuMDAwMCBIICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAg
> MCAgMCAgMA0KICAgIDMuMDkzNSAgICAxLjg2NzAgICAgMC4wMDAwIEggICAw
> ICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwDQogIDEgIDIgIDEg
> IDAgIDAgIDAgIDANCiAgMiAgMyAgMSAgMCAgMCAgMCAgMA0KICAzICA0ICAy
> ICAwICAwICAwICAwDQogIDQgIDUgIDEgIDAgIDAgIDAgIDANCiAgNSAgNiAg
> MiAgMCAgMCAgMCAgMA0KICA2ICA3ICAxICAwICAwICAwICAwDQogIDcgIDgg
> IDEgIDAgIDAgIDAgIDANCiAgOCAgOSAgMiAgMCAgMCAgMCAgMA0KICA5IDEw
> ICAxICAwICAwICAwICAwDQogIDIgMTAgIDIgIDAgIDAgIDAgIDANCiAgNiAx
> MCAgMSAgMCAgMCAgMCAgMA0KIDExICA3ICAxICAxICAwICAwICAwDQogMTEg
> MTIgIDEgIDAgIDAgIDAgIDANCiAxMSAxMyAgMSAgMCAgMCAgMCAgMA0KIDEz
> IDE0ICAxICAwICAwICAwICAwDQogMTQgMTUgIDEgIDAgIDAgIDAgIDANCiAx
> NCAxNiAgMSAgMSAgMCAgMCAgMA0KIDE2IDE3ICAxICAwICAwICAwICAwDQog
> MTQgMTggIDEgIDAgIDAgIDAgIDANCiAxOCAxOSAgMSAgMCAgMCAgMCAgMA0K
> IDE4IDIwICAxICA2ICAwICAwICAwDQogMTggMjEgIDEgIDAgIDAgIDAgIDAN
> CiAyMSAyMiAgMSAgMCAgMCAgMCAgMA0KIDExIDIxICAxICAwICAwICAwICAw
> DQogMjEgMjMgIDEgIDYgIDAgIDAgIDANCiAgMSAyNCAgMSAgMCAgMCAgMCAg
> MA0KICAxIDI1ICAxICAwICAwICAwICAwDQogIDQgMjYgIDEgIDAgIDAgIDAg
> IDANCiAgOCAyNyAgMSAgMCAgMCAgMCAgMA0KIDE2IDI4ICAxICAwICAwICAw
> ICAwDQogMTYgMjkgIDEgIDAgIDAgIDAgIDANCiAxNyAzMCAgMSAgMCAgMCAg
> MCAgMA0KIDIwIDMxICAxICAwICAwICAwICAwDQogMjMgMzIgIDEgIDAgIDAg
> IDAgIDANCk0gIEVORA0KJCQkJA0K
> --380388872-788217705-1106676340=:25814
> Content-Type: TEXT/PLAIN; charset=US-ASCII; name="5SD.sdf"
> Content-Transfer-Encoding: BASE64
> Content-ID: <Pin...@gi...>
> Content-Description: 
> Content-Disposition: attachment; filename="5SD.sdf"
> 
> NVNEDQpJTnRjbHNlcnZlMDEyNDA1MTQ1NzJEIDAgICAwLjAwMDAwICAgICAw
> LjAwMDAwICAgIDE0DQogDQogNDkgNTIgIDAgIDAgIDAgIDAgIDAgIDAgIDAg
> IDA5OTkgVjIwMDANCiAgICA0Ljc1ODcgICAgMC40MTQ2ICAgIDAuMDAwMCBD
> ICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDQu
> NzUxMCAgIC0wLjU4NTQgICAgMC4wMDAwIEMgICAwICAwICAyICAwICAwICAw
> ICAwICAwICAwICAwICAwICAwDQogICAgMy44MjQyICAgLTAuMDIxMyAgICAw
> LjAwMDAgQyAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAN
> CiAgICAyLjg3NjMgICAtMC41NDkzICAgIDAuMDAwMCBDICAgMCAgMCAgMCAg
> MCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDIuODY3OSAgIC0xLjYz
> NDIgICAgMC4wMDAwIEMgICAwICAwICAwICAwICAwICAwICAwICAwICAwICAw
> ICAwICAwDQogICAgMi4wMDAwICAgLTIuMTMwOSAgICAwLjAwMDAgTyAgIDAg
> IDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICAzLjgwNzYg
> ICAtMi4xNzY3ICAgIDAuMDAwMCBDICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAg
> MCAgMCAgMCAgMCAgMA0KICAgIDQuNzQzMCAgIC0xLjYyNzAgICAgMC4wMDAw
> IEMgICAwICAwICAyICAwICAwICAwICAwICAwICAwICAwICAwICAwDQogICAg
> NC43NDU0ICAgLTIuMjQ3MCAgICAwLjAwMDAgSCAgIDAgIDAgIDAgIDAgIDAg
> IDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICA1LjY0NTEgICAtMi4xNDc4ICAg
> IDAuMDAwMCBDICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAg
> MA0KICAgIDYuNTQzMSAgIC0xLjYyMDAgICAgMC4wMDAwIEMgICAwICAwICAw
> ICAwICAwICAwICAwICAwICAwICAwICAwICAwDQogICAgNi41MjcxICAgLTAu
> NTc4NSAgICAwLjAwMDAgQyAgIDAgIDAgIDIgIDAgIDAgIDAgIDAgIDAgIDAg
> IDAgIDAgIDANCiAgICA1Ljk5MjUgICAtMC44OTI3ICAgIDAuMDAwMCBIICAg
> MCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDUuNjYx
> MCAgIC0wLjA3ODUgICAgMC4wMDAwIEMgICAwICAwICAyICAwICAwICAwICAw
> ICAwICAwICAwICAwICAwDQogICAgNi4xOTgwICAgIDAuMjMxNSAgICAwLjAw
> MDAgSCAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAg
> ICA1LjY2MTAgICAgMC45MjE1ICAgIDAuMDAwMCBDICAgMCAgMCAgMCAgMCAg
> MCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDYuNTI3MSAgICAxLjQyMTUg
> ICAgMC4wMDAwIEMgICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAw
> ICAwDQogICAgNy4zOTMxICAgIDAuOTIxNSAgICAwLjAwMDAgQyAgIDAgIDAg
> IDEgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICA3LjM5MzEgICAg
> MS45MjE1ICAgIDAuMDAwMCBDICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAg
> MCAgMCAgMCAgMA0KICAgIDcuMzkzMSAgIC0wLjA3ODUgICAgMC4wMDAwIEMg
> ICAwICAwICAxICAwICAwICAwICAwICAwICAwICAwICAwICAwDQogICAgNy40
> NTg3ICAgLTAuNjk1MSAgICAwLjAwMDAgSCAgIDAgIDAgIDAgIDAgIDAgIDAg
> IDAgIDAgIDAgIDAgIDAgIDANCiAgICA4LjMzOTMgICAtMC4zODMzICAgIDAu
> MDAwMCBDICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0K
> ICAgIDguOTIyOSAgICAwLjQyMTUgICAgMC4wMDAwIEMgICAwICAwICAwICAw
> ICAwICAwICAwICAwICAwICAwICAwICAwDQogICAgOC4zMzkzICAgIDEuMjI2
> MiAgICAwLjAwMDAgQyAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAg
> IDAgIDANCiAgICA4LjY1MDAgICAgMi4xNzY3ICAgIDAuMDAwMCBPICAgMCAg
> MCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDUuMzc4NyAg
> ICAwLjQwOTggICAgMC4wMDAwIEggICAwICAwICAwICAwICAwICAwICAwICAw
> ICAwICAwICAwICAwDQogICAgNC43NjM1ICAgIDEuMDM0NiAgICAwLjAwMDAg
> SCAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICA0
> LjEzODggICAgMC40MTk0ICAgIDAuMDAwMCBIICAgMCAgMCAgMCAgMCAgMCAg
> MCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDQuMjMyNCAgICAwLjQ0NTMgICAg
> MC4wMDAwIEggICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAw
> DQogICAgMy40MzQzICAgIDAuNDYwNyAgICAwLjAwMDAgSCAgIDAgIDAgIDAg
> IDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICAyLjY3MTggICAgMC4w
> MzYwICAgIDAuMDAwMCBIICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAg
> MCAgMCAgMA0KICAgIDIuMjY0NyAgIC0wLjY1MDYgICAgMC4wMDAwIEggICAw
> ICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwDQogICAgMy40MTAz
> ICAgLTIuNjUyNyAgICAwLjAwMDAgSCAgIDAgIDAgIDAgIDAgIDAgIDAgIDAg
> IDAgIDAgIDAgIDAgIDANCiAgICA0LjIwODUgICAtMi42NDk2ICAgIDAuMDAw
> MCBIICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAg
> IDUuMjQ3OCAgIC0yLjYyMzggICAgMC4wMDAwIEggICAwICAwICAwICAwICAw
> ICAwICAwICAwICAwICAwICAwICAwDQogICAgNi4wNDYwICAgLTIuNjIwNyAg
> ICAwLjAwMDAgSCAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAg
> IDANCiAgICA2Ljc2MTEgICAtMi4yMDA0ICAgIDAuMDAwMCBIICAgMCAgMCAg
> MCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDcuMTUyMyAgIC0x
> LjUwNDYgICAgMC4wMDAwIEggICAwICAwICAwICAwICAwICAwICAwICAwICAw
> ICAwICAwICAwDQogICAgNS40NDkwICAgIDEuNTA0MSAgICAwLjAwMDAgSCAg
> IDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICA1LjA1
> MDUgICAgMC44MTM4ICAgIDAuMDAwMCBIICAgMCAgMCAgMCAgMCAgMCAgMCAg
> MCAgMCAgMCAgMCAgMCAgMA0KICAgIDYuOTI1NiAgICAxLjg5NjQgICAgMC4w
> MDAwIEggICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwDQog
> ICAgNi4xMjg1ICAgIDEuODk2NCAgICAwLjAwMDAgSCAgIDAgIDAgIDAgIDAg
> IDAgIDAgIDAgIDAgIDAgIDAgIDAgIDANCiAgICA4LjAxMzEgICAgMS45MjE1
> ICAgIDAuMDAwMCBIICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAg
> MCAgMA0KICAgIDcuMzkzMSAgICAyLjU0MTUgICAgMC4wMDAwIEggICAwICAw
> ICAwICAwICAwICAwICAwICAwICAwICAwICAwICAwDQogICAgNi43NzMxICAg
> IDEuOTIxNSAgICAwLjAwMDAgSCAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAg
> IDAgIDAgIDAgIDANCiAgICA4LjA4ODMgICAtMC45NTAyICAgIDAuMDAwMCBI
> ICAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAgIDgu
> ODc2NyAgIC0wLjY5MjUgICAgMC4wMDAwIEggICAwICAwICAwICAwICAwICAw
> ICAwICAwICAwICAwICAwICAwDQogICAgOS4zODM4ICAgIDAuMDA2NyAgICAw
> LjAwMDAgSCAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAgIDAN
> CiAgICA5LjM4MzggICAgMC44MzYyICAgIDAuMDAwMCBIICAgMCAgMCAgMCAg
> MCAgMCAgMCAgMCAgMCAgMCAgMCAgMCAgMA0KICAyICAxICAxICAxICAwICAw
> ICAwDQogIDIgIDMgIDEgIDAgIDAgIDAgIDANCiAgMyAgNCAgMSAgMCAgMCAg
> MCAgMA0KICA0ICA1ICAxICAwICAwICAwICAwDQogIDUgIDYgIDIgIDAgIDAg
> IDAgIDANCiAgNSAgNyAgMSAgMCAgMCAgMCAgMA0KICA3ICA4ICAxICAwICAw
> ICAwICAwDQogIDggIDkgIDEgIDYgIDAgIDAgIDANCiAgMiAgOCAgMSAgMCAg
> MCAgMCAgMA0KICA4IDEwICAxICAwICAwICAwICAwDQogMTAgMTEgIDEgIDAg
> IDAgIDAgIDANCiAxMSAxMiAgMSAgMCAgMCAgMCAgMA0KIDEyIDEzICAxICAx
> ICAwICAwICAwDQogMTIgMTQgIDEgIDAgIDAgIDAgIDANCiAxNCAxNSAgMSAg
> NiAgMCAgMCAgMA0KICAyIDE0ICAxICAwICAwICAwICAwDQogMTQgMTYgIDEg
> IDAgIDAgIDAgIDANCiAxNiAxNyAgMSAgMCAgMCAgMCAgMA0KIDE3IDE4ICAx
> ICAwICAwICAwICAwDQogMTggMTkgIDEgIDEgIDAgIDAgIDANCiAxOCAyMCAg
> MSAgMCAgMCAgMCAgMA0KIDIwIDIxICAxICA2ICAwICAwICAwDQogMTIgMjAg
> IDEgIDAgIDAgIDAgIDANCiAyMCAyMiAgMSAgMCAgMCAgMCAgMA0KIDIyIDIz
> ICAxICAwICAwICAwICAwDQogMjMgMjQgIDEgIDAgIDAgIDAgIDANCiAxOCAy
> NCAgMSAgMCAgMCAgMCAgMA0KIDI0IDI1ICAyICAwICAwICAwICAwDQogIDEg
> MjYgIDEgIDAgIDAgIDAgIDANCiAgMSAyNyAgMSAgMCAgMCAgMCAgMA0KICAx
> IDI4ICAxICAwICAwICAwICAwDQogIDMgMjkgIDEgIDAgIDAgIDAgIDANCiAg
> MyAzMCAgMSAgMCAgMCAgMCAgMA0KICA0IDMxICAxICAwICAwICAwICAwDQog
> IDQgMzIgIDEgIDAgIDAgIDAgIDANCiAgNyAzMyAgMSAgMCAgMCAgMCAgMA0K
> ICA3IDM0ICAxICAwICAwICAwICAwDQogMTAgMzUgIDEgIDAgIDAgIDAgIDAN
> CiAxMCAzNiAgMSAgMCAgMCAgMCAgMA0KIDExIDM3ICAxICAwICAwICAwICAw
> DQogMTEgMzggIDEgIDAgIDAgIDAgIDANCiAxNiAzOSAgMSAgMCAgMCAgMCAg
> MA0KIDE2IDQwICAxICAwICAwICAwICAwDQogMTcgNDEgIDEgIDAgIDAgIDAg
> IDANCiAxNyA0MiAgMSAgMCAgMCAgMCAgMA0KIDE5IDQzICAxICAwICAwICAw
> ICAwDQogMTkgNDQgIDEgIDAgIDAgIDAgIDANCiAxOSA0NSAgMSAgMCAgMCAg
> MCAgMA0KIDIyIDQ2ICAxICAwICAwICAwICAwDQogMjIgNDcgIDEgIDAgIDAg
> IDAgIDANCiAyMyA0OCAgMSAgMCAgMCAgMCAgMA0KIDIzIDQ5ICAxICAwICAw
> ICAwICAwDQpNICBFTkQNCiQkJCQNCg==
> --380388872-788217705-1106676340=:25814--
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Cdk-user mailing list
> Cdk...@li...
> https://lists.sourceforge.net/lists/listinfo/cdk-user
> 
> 
> End of Cdk-user Digest
> 

++++++++++++++++++++++++++++++++++++++++
Irilenia (Irene) Nobeli
EMBL - European Bioinformatics Institute
Wellcome Genome Campus
Hinxton
Cambridge CB10 1SD
tel: +44 (0) 1223 492550
fax: +44 (0) 1223 494468
e-mail: no...@eb...

[Cdk-user] CDK 20050125 released (build bugs fixed)

[Egon W. <eg...@us...>]

On Sunday 16 January 2005 01:22, Egon Willighagen wrote:
> a new CDK release (20050116) is ready.

There were a number of build issues with this release. I've addressed these, 
and released 20050125. If you were happy with 20050116 then there is no need 
to download the jan-25 release, but if you had build problems, please try the 
new release and let me know if there are more issues.

BTW, I'm thinking about setting up a mailing list or website, where people can 
post there compile log, so that we can get a good look at what configurations 
are used... Would people be interesting in submitting such (anonymously)?

Egon

-- 
eg...@us...
GPG: 1024D/D6336BA6

[Cdk-user] Graph matching problem

[Irilenia N. <no...@eb...>]

Hi,

I have noticed that there are cases where the graph matching algorithm
seems to return different results for a pair of molecules depending on the
order these molecules are passed onto the method getOverlaps of the class
UniversalIsomorphismTester. I don't mean that the mappings are different
(which they should be as they are projections always on the first
molecule) but that the maximum common structure returned has a different
size. I may be wrong, but this looks like a bug.

For example, take the two molecules attached as MDL files. If you run
UniversalIsomorphismTester.getOverlaps(mol1, mol2) on these two, in
one case
you get a clique of 2 atoms, in the other a clique of 11 atoms. These two
molecules both have hydrogens in the original file. If the hydrogens are
removed, you get mappings with the same number of atoms, regardless of
which molecule is first and which is second, i.e. the problem is not there
anymore (actually there could be other examples where even after removal
of hydrogens the problem remains - I just haven't come across them yet).

Well, if anyone has any ideas why this happens, I could do with some help.

Thanks,

Irilenia

++++++++++++++++++++++++++++++++++++++++
Irilenia (Irene) Nobeli
EMBL - European Bioinformatics Institute
Wellcome Genome Campus
Hinxton
Cambridge CB10 1SD
tel: +44 (0) 1223 492550
fax: +44 (0) 1223 494468
e-mail: no...@eb...

Re: [Cdk-user] Fwd: [Biojava-l] BOSC 2005

[Egon W. <e.w...@sc...>]

On Sunday 23 January 2005 02:19, Rajarshi Guha wrote:
> On Fri, 2005-01-21 at 11:51 +0100, Egon Willighagen wrote:
> > Presence of Jmol and/or CDK would be nice...
>
> Hmm, true. Are there any bioinformatics oriented features in CDK and has
> anybody used the CDK for a bioinformatics related application?

There are people working on protein in CDK. I have a patch waiting for better 
protein support, but haven't had time this weekend to carefull look at it. 
Probably will merge it this week...

Moreover, protein structures can displayed in Jmol using the CdkJmolAdapter, 
including secondary structures etc...

> One application that I can think off is the use of the Bioconductor
> project from within CDK - its a set of packages for R, and so fits in
> with the R-CDK framework.
>
> (I apologize for my obsession with R & CDK :)

Yes, something like that... Myself, I'm starting to look for some work on KEGG 
using CDK...

Egon

-- 
e.w...@sc...
PhD student on Molecular Representation in Chemometrics
Radboud University Nijmegen
http://www.cac.science.ru.nl/people/egonw/
GPG: 1024D/D6336BA6

Re: [Cdk-user] Fwd: [Biojava-l] BOSC 2005

[Rajarshi G. <rx...@ps...>]

On Fri, 2005-01-21 at 11:51 +0100, Egon Willighagen wrote:
> Presence of Jmol and/or CDK would be nice...

Hmm, true. Are there any bioinformatics oriented features in CDK and has
anybody used the CDK for a bioinformatics related application?

One application that I can think off is the use of the Bioconductor
project from within CDK - its a set of packages for R, and so fits in
with the R-CDK framework.

(I apologize for my obsession with R & CDK :)


-------------------------------------------------------------------
Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net>
GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
-------------------------------------------------------------------
All great ideas are controversial, or have been at one time.

Re: [Cdk-devel] Re: [Cdk-user] Problem compiling new version

[Egon W. <eg...@us...>]

On Friday 21 January 2005 21:29, Egon Willighagen wrote:
> The classes were added to be able to compile CDK with free Java compilers
> like gcj and kaffe, but that don't have the JavaDoc environment. However,
> apperently I compiled these classes with Java1.5 leading to errors about
> wrong version numbers...

I've just figured out how to upload 1.4 compiled classes. Just recompiling 
seem to have lead to class files that did not differ from CVS... or least, 
CVS would not commit new ones... fortunately, there were a few things I could 
change in the class sources, so 1.4 compiled classes are now in CVS.

Egon

-- 
eg...@us...
GPG: 1024D/D6336BA6

Re: [Cdk-user] Problem compiling new version

[Egon W. <eg...@us...>]

On Thursday 20 January 2005 12:21, Irilenia Nobeli wrote:
> Has anyone else not been able to compile the latest version from CDK?
> Do you need to have Java 1.5 for this, or would 1.4 do as well?

Java 1.4 should work. Please try to delete ALL *.class files in doc/javadoc
and run your ant command again.

The classes were added to be able to compile CDK with free Java compilers like 
gcj and kaffe, but that don't have the JavaDoc environment. However, 
apperently I compiled these classes with Java1.5 leading to errors about 
wrong version numbers...

Irilenia, please let me know if that does not fix your problem.

Egon

-- 
eg...@us...
GPG: 1024D/D6336BA6

[Cdk-user] Fwd: [Biojava-l] BOSC 2005

[Egon W. <e.w...@sc...>]

Presence of Jmol and/or CDK would be nice...

Egon


----------  Forwarded Message  ----------

Subject: [Biojava-l] BOSC 2005
Date: Thursday 20 January 2005 06:58 pm
From: Darin London <dl...@eb...>
To: ope...@op..., au...@op..., 
bak...@bi..., bi...@op..., bio...@op..., 
bio...@bi..., bio...@bi..., 
bio...@po..., bio...@po..., 
bio...@bi..., bio...@bi..., 
bio...@bi..., bio...@bi..., 
bio...@bi..., bi...@op..., bio...@op..., 
bos...@op..., da...@bi..., das...@bi..., 
dyn...@bi..., mob...@bi..., mob...@bi..., 
mo...@bi..., obf...@op..., ens...@eb...

 {Please pass the word!}

 MEETING ANNOUNCEMENT & CALL FOR SPEAKERS

 The 6th annual Bioinformatics Open Source Conference (BOSC'2005) is
 organized by the not-for-profit Open Bioinformatics Foundation. The meeting
 will take place June 23-24, 2005 in Detroit, Michigan, USA, and is one of
 several Special Interest Group (SIG) meetings occurring in conjunction with
 the 13th International Conference on Intelligent Systems for Molecular
 Biology.

 see http://www.iscb.org/ismb2005 for more information.

 Because of the power of many Open Source bioinformatics packages in
 use by the Research Community today, it is not too presumptuous to say
 that the work of the Open Source Bioinformatics Community represents
 the cutting edge of Bioinformatics in general. This has been repeatedly
 demonstrated by the quality of presentations at previous BOSC conferences.
 This year, at BOSC 2006, we want to continue this tradition of excellence,
 while presenting this message to a wider part of the Research Community.
 Please, pass this message on to anyone you know that is interested in
 Bioinformatics software.


 BOSC PROGRAM & CONTACT INFO

 * Web: http://www.open-bio.org/bosc2005/
 * Email: bo...@op...

 FEES

  TO BE ANNOUNCED. Watch the bosc website for more information.


 SPEAKERS & ABSTRACTS WANTED

 The program committee is currently seeking abstracts for talks at BOSC
 2005. BOSC is a great opportunity for you to tell the community about
 your use, development, or philosophy of open source software development
 in bioinformatics. The committee will select several submitted abstracts
 for 25-minute talks and others for shorter "lightning" talks. Accepted
 abstracts will be published on the BOSC web site.

 If you are interested in speaking at BOSC 2005,
 please send us before April 26, 2005:

 * an abstract (no more than a few paragraphs)
 * a URL for the project page, if applicable
 * information about the open source license used for your software or
   your release plans.

 Abstracts will be accepted for submission until April 26, 2005.
 Abstracts chosen for presentation will be announced May 12, 2005
 (before the ISMB Early Registration Deadline).

 LIGHTNING-TALK SPEAKERS WANTED!

 The program committee is currently seeking speakers for the lightning
 talks at BOSC 2005. Lightning talks are quick - only five minutes
 long - and a great opportunity for you to give people a quick
 summary of your open source project, code, idea, or vision of the future.

 If you are interested in giving a lightning talk at BOSC 2005,
 please send us:

 * a brief title and summary (one or two lines)
 * a URL for the project page, if applicable
 * information about the open source license used for your software or
   your release plans.

 We will accept entries on-line until BOSC starts, but
 space for demos and lightning talks is limited.<br/>

 SOFTWARE DEMONSTRATIONS WANTED!
 If you are involved in the development of Open Source Bioinformatics
 Software, you are invited to provide a short demonstration to attendees of
 BOSC 2005.

 If you are interested in giving a software demonstration at BOSC 2005,
 please send us:

 * a brief title and summary (one or two lines)
 * a URL for the project page, if applicable
 * Internet connectivity requirements (e.g. website Application served on the
   world wide web, or web based client application).

   We will accept entries on-line until the BOSC starts, but
   space for demos and lightning talks is limited.

** Because the mission of the OBF is to promote Open Source software, we will
 favor submissions for projects that apply a recognized Open Source License,
 or adhere to the general Open Source Philosophy. See the following websites
 for further details:
   href="http://www.opensource.org/licenses/
   href="http://www.opensource.org/docs/definition.php


  SESSION CHAIRS WANTED
  If you would like to be involved BOSC 2005, we invite you to chair a
 session.  This will not require much of your time.  You will be given a
 schedule of presenters during your session. You simply introduce each
 speaker, and manage the time of their presentation (25 minutes for full
 presentations, 5-10 minutes for lightning talks/demos, depending on the
 number of entries).

  If you are interested in chairing a session, please send us your name and
 affiliation (if applicable).

--
cheers,

Darin London dl...@eb...    European Bioinformatics Institute,
+44 (0)1223 49 2566               Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)         Cambridgeshire CB10 1SD, UK

-------------------------------------------------------

Re: [Cdk-user] Problem compiling new version

[Rajarshi G. <rx...@ps...>]

On Thu, 2005-01-20 at 11:21 +0000, Irilenia Nobeli wrote:

> The error from ant reallyRunDoclet is: 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>   [javadoc] Constructing Javadoc information...
>   [javadoc] 1 error
>   [javadoc]
> /scratch/Downloads/cdk-source-20050116/src/org/openscience/cdk/applications/SubstructureFinder.java:34:
> cannot access org.openscience.cdk.smiles.smarts.SMARTSParser
>   [javadoc] bad class file:
> /scratch/Downloads/cdk-source-20050116/cdk-j1.5-20050116.jar(org/openscience/cdk/smiles/smarts/SMARTSParser.class)
>   [javadoc] class file has wrong version 49.0, should be 48.0
>   [javadoc] Please remove or make sure it appears in the correct
> subdirectory of the classpath.
>   [javadoc] import org.openscience.cdk.smiles.smarts.SMARTSParser;
>   [javadoc]                                          ^
>   [javadoc] Generating Javadoc
>   [javadoc] Javadoc execution
>   [javadoc] javadoc: Cannot find doclet class MakeCDKSetFilesDoclet
>   [javadoc] 1 error
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

It compiles with 1.5 though I have'nt tried it with 1.4.

However I did notice the class version error with another Java source
package I was trying to compile and that stemmed from me mixing ant and
JDK versions - that might be the problem here.

-------------------------------------------------------------------
Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net>
GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
-------------------------------------------------------------------
A computer lets you make more mistakes faster than any other invention,
with the possible exceptions of handguns and Tequilla.
-- Mitch Ratcliffe

[Cdk-user] Problem compiling new version

[Irilenia N. <no...@eb...>]

Hi,

Has anyone else not been able to compile the latest version from CDK?
Do you need to have Java 1.5 for this, or would 1.4 do as well?

The error from ant reallyRunDoclet is: 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  [javadoc] Constructing Javadoc information...
  [javadoc] 1 error
  [javadoc]
/scratch/Downloads/cdk-source-20050116/src/org/openscience/cdk/applications/SubstructureFinder.java:34:
cannot access org.openscience.cdk.smiles.smarts.SMARTSParser
  [javadoc] bad class file:
/scratch/Downloads/cdk-source-20050116/cdk-j1.5-20050116.jar(org/openscience/cdk/smiles/smarts/SMARTSParser.class)
  [javadoc] class file has wrong version 49.0, should be 48.0
  [javadoc] Please remove or make sure it appears in the correct
subdirectory of the classpath.
  [javadoc] import org.openscience.cdk.smiles.smarts.SMARTSParser;
  [javadoc]                                          ^
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] javadoc: Cannot find doclet class MakeCDKSetFilesDoclet
  [javadoc] 1 error
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Thanks,

Irilenia

++++++++++++++++++++++++++++++++++++++++
Irilenia (Irene) Nobeli
EMBL - European Bioinformatics Institute
Wellcome Genome Campus
Hinxton
Cambridge CB10 1SD
tel: +44 (0) 1223 492550
fax: +44 (0) 1223 494468
e-mail: no...@eb...

Re: [Cdk-user] Need Help with molecularviewer3d

[Egon W. <e.w...@sc...>]

On Wednesday 19 January 2005 08:31 am, A P wrote:
>     I am using MolecularViewer3D class to view molecule but when I call its
> display method it creates blank frame . Do we need to do some processing
> with the molecule which is passed to the constructor? or do we have to set
> some properties of renderer3D?

The Renderer3D is not well maintained... and know no one who is using it. Do 
you really need OpenGL graphics? Otherwise, consider using Jmol:

http://wiki.jmol.org/JmolCdkIntegration

Egon

[Cdk-user] Need Help with molecularviewer3d

[A P <ap...@re...>]

 hi=0A    I am using MolecularViewer3D class to view molecule but when I ca=
ll its display method it creates blank frame . Do we need to do some proces=
sing with the molecule which is passed to the constructor? or do we=0Ahave =
to set some properties of renderer3D?=0AAP   =0A=20

Re: [Cdk-user] bibliography page on website - possible error?

[Egon W. <e.w...@sc...>]

On Sunday 16 January 2005 10:57 pm, Rajarshi Guha wrote:
> Hi, the bibliogrpahy page on the website appears to have the tags (eg.
> BRE85) repeated. 

Indeed. Please file a but report...

> Also, has the page been updated with the latest verison 
> of the CDK bibliography?

It should. It's generated from doc/refs/cheminf.btx...

If not consistent, please file a bug report for that too...

E

[Cdk-user] bibliography page on website - possible error?

[Rajarshi G. <rx...@ps...>]

Hi, the bibliogrpahy page on the website appears to have the tags (eg.
BRE85) repeated. Also, has the page been updated with the latest verison
of the CDK bibliography?


-------------------------------------------------------------------
Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net>
GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
-------------------------------------------------------------------
Absence is to love what wind is to fire. It extinguishes the small,
it enkindles the great.

[Cdk-user] CDK 20050116 release

[Egon W. <eg...@us...>]

Hi all,

a new CDK release is ready. It will be on SF shortly, but there upload FTP 
server is full :(   I hope to be able to upload it tomorrow.

Many, many changes, amongst which more than 10 bug fixes [1]. New features 
include:
- a 3D structure generator
- many new QSAR descriptors, amongst which WHIM and BCUT
- an iterating SMILES parser for .smi files
- stable data module (see email yesterday)

For a full overview of features in the library can be found on the index page 
online [2].

Egon

1. http://cdk.sourceforge.net/changelog.html
2. http://cdk.sourceforge.net/keywordindex.html

-- 
eg...@us...
GPG: 1024D/D6336BA6

[Cdk-user] Stableness of CDK's core and data modules

[Egon W. <eg...@us...>]

Dear CDK users and developers,

This email contains important information about the quality state of the CDK 
library.

About a week ago, I finished completing adding all JUnit test for the CDK core 
module. JavaDoc and PMD requirements were met earlier. So, the core module is 
now declared 'stable' [1]. Well, almost, there is one known bug left in the 
cloning method of Reaction.

Ok, however, there is some other important news.

Core is not longer what it used to be.

The old core module, which contained the data storage classes, is has been 
renamed to data (so, cdk-data.jar). And, the core module is now the set of 
core algorithms in the CDK; basically, what the standard module now is.

But, the difference between standard and core is that only 'stable' algorithm 
can go into core. At the time of writing, this only is the LoggingTool, but I 
hope soon will follow in the next weeks.

With the definition of stable we hope to make more clear what the status is of 
the implementations of algorithms in CDK. Sofar, we only had the experimental 
module, for which I hope it is clear what the state of implementation is.

Finally, it's worth noting that these qualifications only say something about 
the implementation, not about the algorithm itself! An implementation can be 
stable, while being very limited, or using a too simplistic.

And, also: a unstable implementation may still hold a very good implementation 
of an very usefull algorithm, which only does not meet our requirements yet.

I hope all this is a bit clear, if not, please ask which parts are unclear, 
and I will try to give more details on those.

Egon



[1] Since this is the first time email on the stableness goes to the user list 
(I think), I'll again give the definition of stable. A stable CDK module 
requires that:
a. all classes and all public methods are tested with JUnit
b. all classes and all public methods have meaningful JavaDoc 
c. source code of all classes are tested against PMD tests defined for
    stableness
This does not mean that there are no bugs in the source code, but at least 
garantee that we make very sure that bugs are very difficult to make.

-- 
eg...@us...
GPG: 1024D/D6336BA6

Re: [Cdk-user] SmilesParser and aromaticity

[E.L. W. <e.w...@sc...>]

Op Thursday 23 December 2004 15:11, schreef Irilenia Nobeli:
> When SMILES are read in with the SmilesParser, aromaticity is generally
> well recognised if single and double bonds are explicitly given. However,
> if the atoms themselves are represented as aromatic, then aromaticity
> detection does not work well.
> Example: NC1=C2C(=NC=N1)[NH]C=N2 (adenine) is recognised as aromatic.
> If it is represented as: Nc1ncnc2[nH]cnc12, it is not!
> However, benzene works ok as c1ccccc1.
>
> Anyone has come across this before? Seems like a bug.

I think this is caused by an bug in the atom type list which was recently 
(post last release) was found... a N.sp2 atom was defined to have 3 
neighbours instead of 2... this is fixed in the next release, to be released 
around new year.

I've not added a bug test to CVS yet for your report, but will do at a later 
stage, but am pretty sure the above issue is causing the malfunction your 
noted.

BTW, the full list is online at the website:

http://cdk.sf.net/ -> Documentation -> Atom Type Lists

and then the hybridization atom type list. I don't think it's in sync with CVS 
yet, so you might actually still see the bad definition of N.sp2 atom type.

Egon