Skip to main content

Alternative Molecule Generation Implementation using the CDK and Signatures

Over the weekend, I cobbled together some components that I've been developing for a while (the past four years in fact) to make a molecule structure generator. As described in recent posts, OMG is one new available solution; now here is a proof-of-concept for a quite similar one.

So what are the differences? Well, firstly OMG uses NautY to check candidates for canonicity while this implementation uses signatures, so is currently slower. The major difference, though is the algorithm. While OMG uses bond-augmentation of a parent structure to make children, this one uses atom-augmentation. Here is a small example (augmenting ethane):

Of course, these are only the immediate children of the C-C parent; for OMG the unique, canonical ones will themselves be augmented further until they are the right size and have the correct number of hydrogens. The atom-augmentation algorithm, by contrast, produces a next generation with exactly one new atom, but a different number of bonds.

The slightly tricky part was to generate all possible combinations of bonds to add. There might be many ways to do this, but the way I picked was this:


Here we are augmenting the C=C(O)C structure on the left to get a cyclobuten-1-ol on the right. First, the atoms that can be added to are calculated using the bond-order sum (bos) : only atoms that are 'undersaturated' can have new bonds. Then all possible multisets are generated, up to the max degree of the added atom (so: {{1,1,1,1}, {1, 1, 2}, {2, 2}...). Finally these multisets are converted to 'bond order arrays' which are just a list of bond orders to attach to each atom.

For the child-filtering approach used in OMG, the algorithm is much the same. For the alternative 'symmetry' approach, the automorphism group of the parent is used to select the bond order array that is minimal in its orbit. Either way, a set of non-redundant children is produced which can then be tested for canonicity.

At the moment, this implementation has had a small amount of testing on alkene (CnH2n) structures to check that it gets the numbers right, but more rigorous testing on different series is necessary. Then some optimisations could be tried to get the time closer to OMG (at least).

Comments

Tobias said…
Hi,
any chance of providing a compiled JAR file and readme.txt
with examples for the command line such as java -jar AMG.jar C6H6

Of course SDF file generation would be important, to validate
with INCHIKeys.

Cheers
Tobias
11 October 2012 at 05:21
gilleain said…
Hi Tobias,

I'll give it a go, although at the moment the element handling is very limited, although there are no technical barriers to expanding it. It also could be better tested, and better optimized, and (as you rightly point out) better documented.

gilleain
11 October 2012 at 08:41
Post a Comment

Popular posts from this blog

Adamantane, Diamantane, Twistane

After cubane, the thought occurred to look at other regular hydrocarbons. If only there was some sort of classification of chemicals that I could use look up similar structures. Oh wate, there is . Anyway, adamantane is not as regular as cubane, but it is highly symmetrical, looking like three cyclohexanes fused together. The vertices fall into two different types when colored by signature: The carbons with three carbon neighbours (degree-3, in the simple graph) have signature (a) and the degree-2 carbons have signature (b). Atoms of one type are only connected to atoms of another - the graph is bipartite . Adamantane connects together to form diamondoids (or, rather, this class have adamantane as a repeating subunit). One such is diamantane , which is no longer bipartite when colored by signature: It has three classes of vertex in the simple graph (a and b), as the set with degree-3 has been split in two. The tree for signature (c) is not shown. The graph is still bipartite accordin
2 comments
Read more

Király's Method for Generating All Graphs from a Degree Sequence

After posting about the Hakimi-Havel  theorem, I received a nice email suggesting various relevant papers. One of these was by Zoltán Király  called " Recognizing Graphic Degree Sequences and Generating All Realizations ". I have now implemented a sketch of the main idea of the paper, which seems to work reasonably well, so I thought I would describe it. See the paper for details, of course. One focus of Király's method is to generate graphs efficiently , by which I mean that it has polynomial delay. In turn, an algorithm with 'polynomial delay' takes a polynomial amount of time between outputs (and to produce the first output). So - roughly - it doesn't take 1s to produce the first graph, 10s for the second, 2s for the third, 300s for the fourth, and so on. Central to the method is the tree that is traversed during the search for graphs that satisfy the input degree sequence. It's a little tricky to draw, but looks something like this: At the top
5 comments
Read more

General Graph Layout : Putting the Parts Together

An essential tool for graph generation is surely the ability to draw graphs. There are, of course, many methods for doing so along with many implementations of them. This post describes one more (or perhaps an existing method - I haven't checked). Firstly, lets divide a graph up into two parts; a) the blocks, also known as ' biconnected components ', and b) trees connecting those blocks. This is illustrated in the following set of examples on 6 vertices: Trees are circled in green, and blocks in red; the vertices in the overlap between two circles are articulation points. Since all trees are planar, a graph need only have planar blocks to be planar overall. The layout then just needs to do a tree layout  on the tree bits and some other layout on the embedding of the blocks. One slight wrinkle is shown by the last example in the image above. There are three parts - two blocks and a tree - just like the one to its left, but sharing a single articulation point. I had
2 comments
Read more