Take the 2-minute tour ×
Theoretical Computer Science Stack Exchange is a question and answer site for theoretical computer scientists and researchers in related fields. It's 100% free, no registration required.

I have a 3d Delaunay triangulation and I construct a Voronoi diagram from it. I have a computation algorithm: for each node of the Voronoi diagram compute a value based on values that neighbouring nodes have. I would like to run this algorithm in parallel in the public cloud. Unfortunately, I cannot find a way to split my graph for maximum computation efficiency. All of my workers end up hitting the network to access neighbouring nodes. I need a way to split my graph to minimise network I/O between workers.

Ideally I want to split my graph into (approximately) balanced parts and minimize the number of edges crossing the parts.

I thought that ordering all nodes in some kind of 'locality-preserving' order is an option since I might not know upfront how many workers I have.

share|improve this question
    
cause I didn't know that it was about graph theory in the beginning. I now got hints that I'm after kernighan-lin algorithm. –  Dima Jan 15 '12 at 21:44
    
On the z-order, points that are close in the original space are often, but not guaranteed to be close to each other in the z order. –  Joe May 13 '12 at 17:44
1  
downvoting: it's not clear what the OP is asking. if he wants z-order, then there is no question. otherwise please define "locality preserving order": is this just a low distortion embedding onto a line? the graph-theory part confuses matters even more. which one of the several dozen defenitions of community are we to assume? the link given points to Newman's modularity, but then he mentions kernighan-lin which is a heuristic for sparse cut. is the question about algorithms to maximize modularity? –  Sasho Nikolov May 15 '12 at 16:20
    
@SashoNikolov I have a 3D veronoi diagram. I have a computation algorithm: for each node compute a value based on values that neighbouring nodes have. I would like to run this algorithm in parallel in the public cloud. Unfortunately, I cannot find a way to split my graph for maximum computation efficiency. All of my workers end up hitting the network to access neighbouring nodes. I need a way to split my graph to minimise network I/O between workers. –  Dima May 15 '12 at 20:32
    
so are you looking to partition a planar graph into some specified number of balanced parts while minimizing the number of edges that go between the parts? something like a $k$-part generalization of balanced cut on a planar graph? if so, you can update your question and you'll probably get more useful answers. for definition of balanced cut: pages.cs.wisc.edu/~shuchi/courses/880-S07/scribe-notes/… –  Sasho Nikolov May 15 '12 at 20:54
show 2 more comments

3 Answers

One natural thing would be to try a separator kind of trick. If the Voronoi cells are fat, and of similar size then a randomly shifted grid of the right side would do reasonably well. in particular, there is a paper by Miller and Thurston (and some other people - their names escape me) about finding a separator if you have fat regions covering space, and every point is covered only a constant number of times. It is essentially an extension of their proof of the existence of a planar separator to these more general settings.

share|improve this answer
add comment

Non-optimal tricks I might use:

1) Use a force directed graph drawing program, then use the layout coordinates to generate a quadtree(z-curve).

2) Use k-means, with k= 3, and distance being the shortest path length. Then recursively apply the kmeans to each cluster. You will get something close to the notion of a space filling curve. When you subdivide one cell into three, use the distance between the generator for each of the three children and the two generators of the other two parent level cells to determine the ordering. For the highest level ordering just pick something.

share|improve this answer
    
Not sure why I picked k=3, guess it just felt more like a SFC if I applied it to a 2d grid graph. With k=2 you should get a layout that looks more like a k-d tree. –  Chad Brewbaker May 15 '12 at 21:46
add comment

I don't see how the fact that the graph results from a voronoi diagram substantially changes the problem. You have a graph and want to do a k-cut, where k is the number of your workers. Instead of minizing just the cut, you also want to make the partitions equal in size.

There is a ridiculously simple heuristic for k-kut. Pick an edge at random and merge the nodes at both endpoints. Repeat, until desired number of components is reached. Try again from the beginning, until bored. Output best result.

This works, because expensive cuts have lots of edges that could get picked, while cheap cuts have few and are therefore selected less often.

Normally, the problem is formulated with edge weights, and edges get picked at nonuniform probabilities, scaled by their weight. If you would instead pick edges with probabilities scaled in such a way, that it favors equally sized components, it should be possible to find a heuristic that gets good results for both minimizing cut size and spreading nodes equally.

I'd suggest to weight the edges according to the number of nodes in the original graph that the resulting node would represent. Edges which represent multiple edges in the original graph, should also get higher probability (their weights start at one, but must still be aggregated on a merge). The resulting probability to pick an edge would be: (number of edges in the original graph the edge represents) / (number of nodes both endpoints represent in the original graph, combined). Off course, this needs to be normalized to 1.

In this way the components would grow at roughly equal speeds, and components which are well connected are merged together with higher preference. I just tried this with a small pen and paper example, and it seems to actually work out just like that.

Depending on whether your problem suffers more from unequal work loads or too much network access, you can tune the probabilities to prefer merging due to high edge count over merging due to low node count or vice versa.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.