I have a large database composed of observations of icebergs. Successive observations of the same iceberg, or observations of pieces that have broken away from the main iceberg, are connected using unique identifiers of each iceberg ("inst") and the preceding observation of that iceberg ("motherinst").
I need to isolate the branches of the iceberg "tree". I need to isolate the branch that follows the iceberg with the largest surface area. If a smaller iceberg breaks away, I need to start following that iceberg too.
Using igraph, I currently have the surface area ("area") assigned as a vertices attribute, but I suspect that this will need to be re-assigned as an edge attribute to weight the edges.
Here is a sample from the database that, with the code here, I have used to produce the plot (below).
g10 <- graph_from_data_frame(edgelist_df)
V(g10)$area=round(edgelist_df$area, digits = 1)[match(V(g10)$name, edgelist_df$inst)]
par(mar=c(0,0,0,0))
plot(g10, vertex.label = V(g10)$area)
In this example plot, the vertices are labelled with the size of each iceberg. Each branch that I am trying to isolate is circled. The red indicates the original icebergs. The blue indicates icebergs that have broken away. The green indicates icebergs that have broken away again. I need to isolate all of these branches]
Thank you for your help!
Related
I've been trying to find a way to replicate the following network graph format in R using DiagrammeR/GraphViz, but without success (ignore the thick black arrow on N1): https://i.stack.imgur.com/oHpQz.png
The graph is a directed graph and each edge in a certain direction either ends with an arrowhead (-->) if the edge value is positive, or a circle/odot (--o) if the edge value is negative. Between a pair of nodes (ex. N1 -- A1), there can be an edge N1 --> A1 and an edge A1 --o N1, and these need to be concentrated so that the two edges look like one line with an arrowhead on one end and a circlehead on the opposite end (like this: o--->). These cannot be parallel or look like two edges ideally.
Another requirement is that the nodes have to be in very specific positions and remain there throughout model simulations where edges might change. From what I have tried and the documentation I have read, this is not possible to do in DOT format, but is possible in neato format.
This is where I get a problem. In neato, I can align the nodes exactly where I want them by defining their x,y positions. However, when I use concentrate = true to create the o---> edge from two otherwise parallel edges, only one type of arrowhead remains. So an edge that's supposed to look like o---> ends up looking like ---> or o---.
This is not a problem in DOT format as concentrate = true does what I want it to do, but in DOT I cannot assign exact node positions. I have tried getting around this using node ranks but without much luck. It seems to stack nodes I want in different ranks within the same rank. As well, concentrate = true doesn't seem to work for edges between nodes within the same rank, as it leaves them as two separate curved edges ---> and o--- without concentrating them.
The reason why I need this to work is because I'm running model simulations where the edges change, and I need to generate hundreds of such graphs. For easy comparison, the nodes need to stay in the same place for consistency.
This is the closest I could come up with using neato format (nodes are positioned the way I want but it's not showing the proper o---> for all the black edges minus self-edges; red edges are true one-way links): https://i.stack.imgur.com/YJBY7.jpg
If only the edges showed up as the proper o---> format, this would be perfect for my needs. If you know of any way to fix this issue using DiagrammeR/GraphViz, or even another program, I would be so grateful. Thanks!
You probably don't need concentrate. Look at arrowtail and dir (https://www.graphviz.org/doc/info/attrs.html#d:arrowtail and https://www.graphviz.org/doc/info/attrs.html#d:dir) and neato -n
digraph c {
graph[label="can neato do the work?"]
node[shape=circle]
a [pos="100,100"]
b [pos="200,100"]
c [pos="300,100"]
a->b [dir=both arrowtail=odot]
c->c [dir=both arrowtail=odot arrowhead=none]
}
Giving:
I have a polygon in closed (ends in the starting vertex) and simple (no holes inside) form, I'm trying to think of an algorithm that draws lines between vertices such that these conditions are met:
The two sides of the line should have balanced number of vertices (at most 1 more vertex on one side is okay)
When lines join each other they have to make up either an angle of 90 or 135 degrees.
Here's an example image, as you can see the blue lines are drawn such that the above conditions are met:
Hint:
If you project the vertices orthogonally on a line, the vertices of the "sides" of your shape that are well aligned with the projection direction will form clusters, and if you pick one of these clusters, the line that projects onto the median of the cluster will meet your balancing condition.
So a possible path of attack is to consider several initial directions and the ones rotated in the appropriate multiples of 90° and 135°, and study the clusters so obtained.
Needless to say, nothing simple. (But your problem isn't.)
I'm working with some datasets that have a repeated pattern like shown below, often with dozens or hundreds of these peaks. My aim is to identify the average point across all of the peaks where the curve has quickly dropped off and begun to level out (the top arrow). I also want to find the average point where the curve begins to flatten out (the bottom arrow). I'm hoping to use python to identify these points.
In the following plot, there are 26 named nodes (the diamonds; names are a-z), each of which is surrounded by a cluster of 4 points (children). My objective is to show how the children cluster around each node- how many children there are (set to 4 in this artificial example), how far away they are from their parent node, and in what direction.
To this end, it would be helpful if the color contrast between nearby nodes was always large. You can see here that the contrast is in many cases sufficient, but there are problems: Colors for k and l are similar or identical; the same holds for b and c, g and h, etc. Having clusters of similar colors near each other reduces the interpretability of the chart.
It seems to me that there must be a solution to this issue based on something like the four color theorem. For example, if I could define contiguous regions around each node, I could achieve consistent contrast with as little as four colors.
But, I can't figure out a good approach (without sinking more time than this is ultimately worth to me right now!). This seems like the sort of problem that should have a known solution. Does it?
I want to generate a sequence of the number of vertices in all graphs which each edge has the same number of leaving edges. I dont have to generate the whole sequence. Let's say the first 50 if exists.
I want:
Input: the number of edges leaving each vertex
Output: a sequence of the number of vertices
So far, I have looked at complete graphs. Complete graphs with n vertices always have n-1 edges leaving each vertex. But there are other kinds of graphs that have this property. For example, some polyhedrons, such as snub dodecahedron and truncated icosidodecahedron have this property.
How should I approach my problem?
I think you mean regular graphs:
http://en.wikipedia.org/wiki/Regular_graph
http://mathworld.wolfram.com/RegularGraph.html
I made a regular graph generator which isn't flawless by the way:
once you generate the nodes, say from 1 to n. You want regularity r.
For node 1, make connections to the following nodes until you reach degree r for node 1.
For node 2 you already have degree 1 (because of node 1), you connect again to further nodes until you reach degree r for node 2 too. And this way till the last node.
The flaw is that you can't define an r-regular graph for any number of nodes. The algorithm mentioned doesn't detect that, so some errors may occur. Also, this isn't a random r-regular graph generator, but instead give one possible solution.
I'm not much of an explainer, so please ask if the description lacks somewhere.