Atom-typing the Hetgroup Dictionary

So I posted this to CDK-devel, but probably this is the better place...

I've been trying to make a map between the atom IDs used in the HET dictionary (which is in CIF format) and atom types of some sort. To see what this looks like, here is a tail of the file:

ZZZ.O6A:O.sp2
ZZZ.H7C1:H
ZZZ.H7C2:H
ZZZ.H8:H
ZZZ.H2N1:H
ZZZ.H2N2:H
ZZZ.H3:H
ZZZ.H5:H
ZZZ.H6:H
ZZZ.H6A:H

'Zzzz', you may be thinking, but although many atom ids are quite obvious (like H8 is a hydrogen), some are probably not. One annoying aspect of this process was that the CIF file format is not especially friendly, and particularly, the file has 'loop_'s that don't terminate in octothorpes ('#'), as I thought they would.

Probably the parser (an IteratingCIFReader) could be much better written - in fact, it will probably only parse this one CIF! So my initial estimates of 13,000 typing failures is now down to only 3,508. What are the atoms that fail? There are some that are bound to like TBR, which is decidedly a non-organic molecule.

Quite a few, however, are aromatic chlorines:

Null type for 00A CL4A [CL]([C]([C]=[C]))
Null type for 014 CL [CL]([C]([C]=[C]))
Null type for 01A CL4A [CL]([C]([C]=[C]))
Null type for 01W N [N]([C]([C][C][H])[H][H][H])
Null type for 024 BR19 [BR]([C]([C]=[C]))
Null type for 032 CL13 [CL]([C](=[C][C]))
Null type for 039 CL [CL]([C](=[C][C]))
Null type for 055 CL1 [CL]([C](=[C][C]))
Null type for 062 CL1 [CL]([C]([C]=[C]))
Null type for 064 CL13 [CL]([C]([C]=[C]))
Null type for 064 CL15 [CL]([C](=[C][C]))
Null type for 064 CL25 [CL]([C](=[C][C]))
Null type for 088 CL32 [CL]([C](=[C][C]))
Null type for 088 CL37 [CL]([C]([C]=[C]))

The last part is the height-2 signature, just to give a quick idea of the environment of the atom. Aha! Some quick "cut | sort | uniq -c | sort -n" gives me:

24 [BR]([C]([C][H][H]))
29 [CL]([C](=[C][N]))
29 [CL]([C](=[C][S]))
38 [N]([C]([C][C][H])[H][H][H])
42 [N]([C]([C][H][H])[H][H][H])
48 [CL]([C]([C][H][H]))
75 [N]([C]([C][H][H])[C]([H][H][H])[C]([H][H][H])[C]([H][H][H]))
337 [BR]([C]([C]=[C]))
1176 [CL]([C]([C]=[C]))

gives the 'top-10' worst offenders. That nitrogen one is N(CH3)4 - perhaps charge is a problem here?

Comments

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

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

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