Hello, I need the key point of your algorithm is not really clear > • We start with the root such that all edges are possibly > here or not. The upper bound is the sum of the $n \choose 2$ > heaviest edges, while the associated solution is the empty > subgraph, the lower bound is thus 0. > > • Then at each iteration we create two children for the node > with maximum lower bound (i.e. density of the associated > solution). Suppose the node is at depth $i$ in the tree, we > keep the decisions made on the first $i-1$ edges and create > two children, one where the $i^\text{th}$ edge is included and one > where it is not. I need to understand this part in clear way if that is possible please
> I need to understand this part in clear way if that is possible please I see. I agree it is not perfectly clear, sorry about that. Can you try to understand it with the branch and bound [wikipedia page](https://en.wikipedia.org/wiki/Branch_and_bound), [the slides](https://drive.google.com/file/d/0B6cGK503Ibt0Qlg3bUVKRnFBTG8/view) and [the code](https://github.com/maxdan94/HkS)? If it is still not clear after that, please come back and I'll try to phrase a better explanation ASAP.

##To take away:## - This paper is about a slight improvement of the $k$-clique Algorithm of Chiba and Nishizeki - The performance in practice on sparse graphs is impressive - The parallelization is non-trivial and the speedup is nearly optimal up to 40 threads - Authors generate a stream of k-cliques to compute "compact" subgraphs - A parallel C code is available here: https://github.com/maxdan94/kClist ##Suggestions to extend this work:## - Can we find a node ordering better than the core ordering? - Generate a stream of $k$-cliques to compute other quantities? - Generalize the algorithm to $k$-motifs? - Parallelization on higher order $k$-cliques if more threads are available?