NetworkX Compatibility and Transition

Note: this is a work in progress and will be updatred and changed as we better flesh out compatibility issues

One of the goals of RAPIDS cuGraph is to mimic the NetworkX API to simplify the transition to accelerated GPU data science. However, graph analysis, also called network science, like most other data science workflow, is more than just running an algorithm. Graph data requires cleaning and prep (ETL) and then the construction of a graph object; that is all before the execution of a graph algorithm. RAPIDS and cuGraph allow a portion or the complete analytic workflow to be accelerated. To achieve the maximum amount of acceleration, we encourage fully replacing existing code with cuGraph. But sometimes it is easier to replace just a portion.

Last Update

Last Update: Oct 14th, 2020 Release: 0.16

Information on NetworkX

This transition guide in an expansion of the Medium Blog on NetworkX Compatibility

Easy Path – Use NetworkX Graph Objects, Accelerated Algorithms

Rather than updating all of your existing code, simply update the calls to graph algorithms by replacing the module name. This allows all the complicated ETL code to be unchanged while still seeing significate performance improvements.

In the following example, the cuGraph module is being imported as “cnx”. While module can be assigned any name can be used, we picked cnx to reduce the amount of text to be changed. The text highlighted in yellow indicates changes.

It is that easy. All algorithms in cuGraph support a NetworkX graph object as input and match the NetworkX API list of arguments.

Currently, cuGraph accepts both NetworkX Graph and DiGraph objects. We will be adding support for Bipartite graph and Multigraph over the next few releases.

Differences in Algorithms

Since cuGraph currently does not support attribute rich graphs, those algorithms that return simple scores (centrality, clustering, etc.) best match the NetworkX process. Algorithms that return a subgraph will do so without any additional attributes on the nodes or edges.

Algorithms that exactly match

Algorithm	Differences
Core Number	None
HITS	None
PageRank	None
Personal PageRank	None
Strongly Connected Components	None
Weakly Connected Components	None

Algorithms that do not copy over additional attributes

Algorithm	Differences
K-Truss	Does not copy over attributes
K-Core	Does not copy over attributes
Subgraph Extraction	Does not copy over attributes

Algorithms not in NetworkX

Algorithm	Differences
Ensemble Clustering for Graphs (ECG)	Currently not in NetworkX
Force Atlas 2	Currently not in NetworkX
Leiden	Currently not in NetworkX
Louvain	Currently not in NetworkX
Overlap coefficient	Currently not in NetworkX
Spectral Clustering	Currently not in NetworkX

Algorithm where not all arguments are supported

Algorithm	Differences
Betweenness Centrality	weight is currently not supported – ignored endpoints is currently not supported – ignored
Edge Betweenness Centrality	weight is currently not supported – ignored
Katz Centrality	beta is currently not supported – ignored max_iter defaults to 100 versus 1000

Algorithms where the results are different

For example, the NetworkX traversal algorithms typically return a generator rather than a dictionary.

Algorithm	Differences
Triangle Counting	this algorithm simply returns the total number of triangle and not the number per vertex (on roadmap to update)
Jaccard coefficient	Currently we only do a 1-hop computation rather than an all-pairs. Fix is on roadmap
Breadth First Search (BFS)	Returns a Pandas DataFrame with: [vertex][distance][predecessor]
Single Source Shortest Path (SSSP)	Returns a Pandas DataFrame with: [vertex][distance][predecessor]

Graph Building

The biggest difference between NetworkX and cuGraph is with how Graph objects are built. NetworkX, for the most part, stores graph data in a dictionary. That structure allows easy insertion of new records. Consider the following code for building a NetworkX Graph:

# Read the node data
df = pd.read_csv( data_file)

# Construct graph from edge list.
G = nx.DiGraph()

for row in df.iterrows():
    G.add_edge(
        row[1]["1"], row[1]["2"], count=row[1]["3"]
    )

The code block is perfectly fine for NetworkX. However, the process of iterating over the dataframe and adding one node at a time is problematic for GPUs and something that we try and avoid. cuGraph stores data in columns (i.e. arrays). Resizing an array requires allocating a new array one element larger, copying the data, and adding the new value. That is not very efficient.

If your code follows the above model of inserting one element at a time, the we suggest either rewriting that code or using it as is within NetworkX and just accelerating the algorithms with cuGraph.

Now, if your code bulk loads the data from Pandas, then RAPIDS can accelerate that process by orders of magnitude.

The above cuGraph code will create cuGraph.Graph object and not a NetworkX.Graph object.