nx-cugraph: add weakly connected components

[eriknw]

This doesn't currently work, because plc.weakly_connected_components only works on symmetric graphs (so it's not actually performing wcc now is it?):

RuntimeError: non-success value returned from cugraph_weakly_connected_components: CUGRAPH_UNKNOWN_ERROR cuGraph failure at file=[...]/cugraph/cpp/src/components/weakly_connected_components_impl.cuh line=283: Invalid input argument: input graph should be symmetric for weakly connected components.

These are high-priority algorithms for nx-cugraph, because they are widely used by networkx dependents.

[ChuckHastings]

So, I suppose this goes to your definition of weakly connected components. Networkx defines this as you describe:

• components is what we have implemented and finds the connected components of an undirected graph
• weakly_connected_components operates only on a directed graph but computes as if the graph were undirected
• strongly_connected_components operates only on a directed graph and actively considers direction

A quick scan of the literature suggests that while this is perhaps a good labeling (matches Knuth, always a plus in my mind), that it's hardly universal.

Our implementation at the C++ level computes components as defined by networkx. In order to get weakly_connected_components as defined by networkx you would need to symmetrize the edge list. This will give you exactly the correct answer. If you look at the networkx implementation, all it does is traverse the incoming and outgoing edges instead of just one direction, by symmetrizing the graph we get all of the edges going in both directions so we can do it in one pass.

We don't really have an efficient way of traversing the edges backwards from whatever orientation that we have. Our CSR/DCSR representation only efficiently reflects one direction.

We have several options we can pursue:

1. You could symmetrize the input edge list prior to creating the graph (less work for me, but probably not a great long term solution)
2. We have a C++ function that will do this efficiently. We could expose this function via the C API
3. We could add a parameter to the graph construction to let the graph construction call know that we should symmetrize the input prior to constructing the graph.
4. We could add logic to the C API that would symmetrize the graph locally for just the WCC call. If you were to call our WCC algorithm with a directed graph we would execute this logic. The downside of this is that we would double the memory used, since we would presumably have to maintain the unsymmetrized graph as well as the symmetrized graph. This seems like a bad option.

I'm leaning toward option 3, but am open to other options.

[eriknw]

Thanks for the thoughtful and helpful reply @ChuckHastings!

I went ahead with option 1 where we symmetrize in Python before creating the PLC graph. This is probably good enough for a while. Nevertheless, I did it in a way that will let us easily switch to options 2 or 3 if/when available.

I chose the keyword argument symmetrize="union" (used by WCC) and symmetrize="intersection" (will probably use for another algorithm soon).

Related topic: is SCC on your radar to do any time soon? I'm less familiar with SCC algorithms and literature, but maybe https://doi.org/10.14778/2733085.2733089

[ChuckHastings]

Related topic: is SCC on your radar to do any time soon? I'm less familiar with SCC algorithms and literature, but maybe https://doi.org/10.14778/2733085.2733089

We have a low priority activity exploring SCC. Constructing a good algorithm for the GPU is complicated as the best serial algorithms use depth-first search which doesn't parallelize well. I wouldn't expect a good implementation this year unless we find some customer that urgently wants it.

[rlratzel]

LGTM. I did point out something this PR might need from this PR that might make it worth waiting for and updating.

[rlratzel]

LGTM. I had one question below which need not hold up approval.

[rlratzel]

just curious, no action needed: is this expected to always return 0 in this case? If so, is there a reason calling len() is preferred over just returning 0?

[eriknw]

Maybe I should use G.number_of_edges() instead of G.src_indices.size (but for some reason the latter is easier for me to remember and reason about). Anyway, if the number of edges are zero, the the number of components is the number of nodes, hence we can't simply return 0.

[eriknw]

I may update to use number_of_edges lots of places for clarity in a different PR. I agree this shouldn't hold up this PR.

[eriknw]

Oh I see, number_of_edges actually does a lot more work. If we want to know if there are exactly 0 edges, G.src_indices.size works great.

[rlratzel]

/merge