skirkpatrick/isite

C++ implementation of the iSite protein evolution graph algorithm.

isite's Issues

Parallel Edges

Parallel edges between nodes need to be implemented for the seed graph and for duplications. Of note, also, is the fact that this is required in order to properly implement nodes with self-loops between different iSites. I will be working on this next.

Frankenstein nodes

The creation/duplication of nodes with iSites from multiple nodes is a proposed enhancement to be implemented. These are the so-called "Frankenstein nodes" to which Todd referred. These nodes should be indiscriminate to the types of iSites they duplicate (ei, whether or not they contain self-loops).

Homomeric interactions (self-loops)

Self loops need to be implemented, along with heritable homomers (duplicated self-loops). I'll be working on getting that implemented next, as it's the last part of the original iSite model left to be implemented.

Site names not working upon duplication

Site names have not been implemented for duplicated nodes.
Similarly, the site names appear to be incorrect/corrupted for the parent upon duplication as can be seen by comparing the end graph to the debug output for each node's iSite. Not sure about the reason for this, so it'll take some looking into.

Properly implementing the "iterations" argument

Right now the iterations command line argument doesn't do anything (except break the code for any value other than 1). There are two possibilities for how multiple iterations can be properly implemented:

1. Keeping iterations as a command line argument and resetting the seed graph after each iteration
2. Removing iterations as a comman line argument and having it only as an argument to the shell script for the clusters

We may need to ask Todd what he would prefer.

Enhanced debug statements

The current debug statements are. . . less than optimal. Some are not too descriptive (graph state output) and most (read: all) are formatted poorly. My next contribution will be to clean up all the debug statements so they are sufficiently descriptive, easy to read, and are only included where helpful. Suggestions would be great, too.

predecessor array

with BFS / DFS algorithms a pred[] is usually created so you can tell how to get from the finish point back to the start. i feel that we can use the same concept for figuring out the parent / child history from the newest nodes all the way back to the seed graph. This will be easy to do and will just use the vertex descriptor's order of insertion into the graph class. This will be way better than my idea earlier today to have strings as the names of the nodes :)

Purpose of vertexsites::vertex_id

Is there a good reason for having the vertexsites::vertex_id data member? It seems to simply be a copy of the data stored in indexmap. If it doesn't add any functionality, I'll just take it out and replace all references to it with the indexmap.

Duplicated edges not always going into right iSite on connected node

When duplicating nodes, some edges do not connect to the correct iSite on the connected node(s). This is also why sometimes iSites are present in the end-graph with 0 edges (This shouldn't happen because only one edge can be removed: either the parent or the child, but not both). I'll be looking into why this is happening. In the meantime, ignore the comment on line 304; it'll be gone in the next commit.

Update README

The README is out of date. Several debug statements have been changed or are being changed, and info about resulting output should be added.