With the recent release of the Open Molecule Generator (OMG) I thought it would be nice to add to (or augment) the description of the algorithm in the paper. The description here will be in terms of graphs, but the principle is largely the same.
OMG's algorithm is a variant of McKay's canonical path augmentation algorithm, as mentioned before here. However, instead of augmenting by vertex it augments by edges. To illustrate this, consider a diagram for graphs with up to 4 vertices:
The graphs are grouped by vertex count (boxes), and each box is sorted into columns. Along the top are the number of edges for graphs in that column, and along the bottom are number of vertices for graphs in the box. Two graphs are connected by an arrow if the larger can be made from the smaller by adding a single edge.
A couple of important things to note about edge-addition are : 1) two paths can lead to the same graph, and 2) at least one of the graphs is disconnected. The first of these is solved by canonical augmentation; a bond is only added if it is the inverse of a canonical deletion. For example:
The image above shows two parent graphs on the left, and an extension of each on their right. The extensions are isomorphic, and have the same canonical form on the far right. The canonical deletion edge is 2:3 - which maps to 0:3 in both graphs. Only one extension is equivalent to the canonical deletion edge.
The second problem - that of disconnected graphs - is only a problem if the canonicalisation routine cannot handle such graphs. Unfortunately, this currently applies to signatures; luckily OMG uses nauty for this part, which doesn't suffer from this limitation. An example of extending a disconnected graph is shown below:
Clearly connected graphs can be constructed from disconnected ones, although it is possible that a canonicalisation method could be designed that avoided disconnected parents. In other words, one that only chose edges that didn't separate the graph.
One final important point is that the OMG algorithm cannot proceed by extending every member of the set of graphs G(n) on n vertices to get non-redundant G(n + 1). For example, extending from both of the members of G(3) will produce multiple copies of one of G(4) - at least, in my test code. This might rule out one easy way to run the program in parallel (running separate subtrees in different processes), but possibly could be solved by using a subset of G(n) to generate the next level.
OMG's algorithm is a variant of McKay's canonical path augmentation algorithm, as mentioned before here. However, instead of augmenting by vertex it augments by edges. To illustrate this, consider a diagram for graphs with up to 4 vertices:
A couple of important things to note about edge-addition are : 1) two paths can lead to the same graph, and 2) at least one of the graphs is disconnected. The first of these is solved by canonical augmentation; a bond is only added if it is the inverse of a canonical deletion. For example:
The image above shows two parent graphs on the left, and an extension of each on their right. The extensions are isomorphic, and have the same canonical form on the far right. The canonical deletion edge is 2:3 - which maps to 0:3 in both graphs. Only one extension is equivalent to the canonical deletion edge.
The second problem - that of disconnected graphs - is only a problem if the canonicalisation routine cannot handle such graphs. Unfortunately, this currently applies to signatures; luckily OMG uses nauty for this part, which doesn't suffer from this limitation. An example of extending a disconnected graph is shown below:
Clearly connected graphs can be constructed from disconnected ones, although it is possible that a canonicalisation method could be designed that avoided disconnected parents. In other words, one that only chose edges that didn't separate the graph.
One final important point is that the OMG algorithm cannot proceed by extending every member of the set of graphs G(n) on n vertices to get non-redundant G(n + 1). For example, extending from both of the members of G(3) will produce multiple copies of one of G(4) - at least, in my test code. This might rule out one easy way to run the program in parallel (running separate subtrees in different processes), but possibly could be solved by using a subset of G(n) to generate the next level.
Comments