1,4-Benzoquinone and the DeduceBondSystemsTool

Once upon a time, there was a DeduceBondSystemsTool, and...

Er, anyway. Further to a patch made on the tool (patch ID : 3040138), there is a failing test for 1,4-benzoquinone:

The tool generates A, and the test wants B. Now, the problem is not that the tool is not trying B as a possibility, but that it generates A first and the final step doesn't remove it or rank it as better than A.

Understanding this requires an understanding of the algorithm. This is (roughly):

For each ring, generate a list of possible positions for all numbers of double bonds.
Generate a set of molecules by combining these positions together.
Remove 'bad' solutions and pick a solution with the least number of 'bad' N/S atoms.

where the definition of 'bad' is based on chemical rules like atom types.

Now, neither A nor B are bad solutions, and they don't contain N or S atoms, so they both have a rank of zero, and the first one generated will be returned. So, there is really no particular reason that the test should pass.

In general, it might be good to separate the generation of possible solutions from the ranking/filtering process. So that the computational or mathematical problem of generation is done by one class, while other classes determine which is the optimal solution (or set of solutions).

Comments

Egon Willighagen said…

If we would know that the O was sp2, then the first solution could be marked as bad. Not sure if that information is available at the DeduceBondSystemTool level...

14 August 2010 at 17:10

gilleain said…

It checks for sp2 atoms, but only in the ring...

This is where a separation between generation and chemical rules would make things clearer. Of course, it would be better to constrain and generate, rather than generate and test.

Another architectural issue is that a bond system generation tool might benefit from detecting symmetric atoms. This would mean new module dependencies (eg, on the signature module).

14 August 2010 at 17:25

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

1,2-dichlorocyclopropane and a spiran

As I am reading a book called "Symmetry in Chemistry" (H. H. Jaffé and M. Orchin) I thought I would try out a couple of examples that they use. One is 1,2-dichlorocylopropane : which is, apparently, dissymmetric because it has a symmetry element (a C2 axis) but is optically active. Incidentally, wedges can look horrible in small structures - this is why: The box around the hydrogen is shaded in grey, to show the effect of overlap. A possible fix might be to shorten the wedge, but sadly this would require working out the bounds of the text when calculating the wedge, which has to be done at render time. Oh well. Another interesting example is this 'spiran', which I can't find on ChEBI or ChemSpider: Image again courtesy of JChempaint . I guess the problem marker (the red line) on the N suggests that it is not a real compound? In any case, some simple code to determine potential chiral centres (using signatures) finds 2 in the cyclopropane structure, and 4 in the

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

Some Stuff

Search This Blog