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
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

Popular posts from this blog

How many isomers of C4H11N are there?

One of the most popular queries that lands people at this blog is about the isomers of C4H11N - which I suspect may be some kind of organic chemistry question on student homework. In any case, this post will describe how to find all members of a small space like this by hand rather than using software.

Firstly, lets connect all the hydrogens to the heavy atoms (C and N, in this case). For example:


Now eleven hydrogens can be distributed among these five heavy atoms in various ways. In fact this is the problem of partitioning a number into a list of other numbers which I've talked about before. These partitions and (possible) fragment lists are shown here:


One thing to notice is that all partitions have to have 5 parts - even if one of those parts is 0. That's not strictly a partition anymore, but never mind. The other important point is that some of the partitions lead to multiple fragment lists - [3, 3, 2, 2, 1] could have a CH+NH2 or an NH+CH2.

The final step is to connect u…

Havel-Hakimi Algorithm for Generating Graphs from Degree Sequences

A degree sequence is an ordered list of degrees for the vertices of a graph. For example, here are some graphs and their degree sequences:



Clearly, each graph has only one degree sequence, but the reverse is not true - one degree sequence can correspond to many graphs. Finally, an ordered sequence of numbers (d1 >= d2 >= ... >= dn > 0) may not be the degree sequence of a graph - in other words, it is not graphical.

The Havel-Hakimi (HH) theorem gives us a way to test a degree sequence to see if it is graphical or not. As a side-effect, a graph is produced that realises the sequence. Note that it only produces one graph, not all of them. It proceeds by attaching the first vertex of highest degree to the next set of high-degree vertices. If there are none left to attach to, it has either used up all the sequence to produce a graph, or the sequence was not graphical.



The image above shows the HH algorithm at work on the sequence [3, 3, 2, 2, 1, 1]. Unfortunately, this produce…

Generating Trees

Tree generation is a well known (and solved!) problem in computer science. On the other hand, it's pretty important for various problems - in my case, making tree-like fusanes. I'll describe here the slightly tortuous route I took to make trees.

Firstly, there is a famous theorem due to Cayley that the number of (labelled) trees on n vertices is nn - 2 which can be proved by using Prüfer sequences. That's all very well, you might well say - but what does all this mean?

Well, it's not all that important, since there is a fundamental problem with this approach : the difference between a labelled tree and an unlabelled tree. There are many more labeled trees than unlabeled :


There is only one unlabeled tree on 3 vertices, but 3 labeled ones
this is easy to check using the two OEIS sequences for this : A000272 (labeled) and A000055 (unlabeled). For n ranging from 3 to 8 we have [3, 16, 125, 1296, 16807, 262144] labeled trees and [1, 2, 3, 6, 11, 23] unlabeled ones. Only 23 …