Open ShivanjaliR opened 9 months ago
Any updates on this issue? any progress?
We will look into this.
1. I realized just like networkx graph object, there should be a facility for the cugraph as well to remove a specific node or list of nodes from the cugraph.
NetworkX uses a dictionary based graph model, which is one reason that graph creation is very slow, but it does allow for data deletion. We use a traditional CSR structure which does not support easy deletion, or addition. Recreating the graph is the only way. cuGraph operates on a cuDF DataFrame, can can simply update the DataFrame and create a new Graph.
With that said, we exploring new data structures and plan to support dynamic graph later this year.
in the case of the node2vec library for CUP, one of the input arguments is a dimension which returns node embedding of the size of dimension but in the case of node2vec library of cugraph, it returns random walks not node embedding, is there any way where I will get node embedding of graph for cugraph.node2vec as well. Just like node2vec in CPU.,
That is something that we will add to our roadmap. Since we plan to redo node2vec to make it support multiple GPUs, making other changes should be easy. I will let you know when the PR is ready, but it will be in thee 24.06 or later release
Any approximate date when that changes are ready to use? As per that I will decide which platform I should use. Till that point do you have any alternative ways ?
On Tue, Mar 12, 2024 at 3:33 PM Brad Rees @.***> wrote:
in the case of the node2vec library for CUP, one of the input arguments is a dimension which returns node embedding of the size of dimension but in the case of node2vec library of cugraph, it returns random walks not node embedding, is there any way where I will get node embedding of graph for cugraph.node2vec as well. Just like node2vec in CPU.,
That is something that we will add to our roadmap. Since we plan to redo node2vec to make it support multiple GPUs, making other changes should be easy. I will let you know when the PR is ready, but it will be in thee 24.06 or later release
— Reply to this email directly, view it on GitHub https://github.com/rapidsai/cugraph/issues/4198#issuecomment-1992393577, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ76XBPAM5YE7K2GMAMIJTYX5KB5AVCNFSM6AAAAABD4ZYILGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJSGM4TGNJXG4 . You are receiving this because you authored the thread.Message ID: @.***>
We closely integrate with the GNN frameworks DGL and PyTorch Geometric, which have node2vec and metapath2vec implementations.
We are actively debugging a C++ implementation of node2vec. I expect the C++ implementation will be ready this month.
Once that is ready we will integrate this into the python code. I would expect this to be included as part of release 24.10.
Is this a new feature, an improvement, or a change to existing functionality?
New Feature
How would you describe the priority of this feature request
Critical (currently preventing usage)
Please provide a clear description of problem this feature solves
Describe your ideal solution
https://docs.rapids.ai/api/cugraph/stable/api_docs/api/cugraph/cugraph.node2vec/
paths, weights, path_sizes = cugraph.node2vec(G, start_vertices, 3, True, 0.8, 0.5)
which returns paths but not its node embedding just like node2vec on cpu version.
node2vec = Node2Vec(graph, dimensions=64, walk_length=30, num_walks=200, workers=4) <-- CPU version
it will return 64 sizes of graph node embedding and I think cugraph should provide such functionality or give guidelines to achieve such particular size embeddings.
Describe any alternatives you have considered
No response
Additional context
No response
Code of Conduct