Question about GATConv source code

If only one input Tensor is given, feat_src and feat_dst would be equal as follows,

h_src = h_dst = self.feat_drop(feat)
            feat_src = feat_dst = self.fc(h_src).view(
                -1, self._num_heads, self._out_feats)
# ...
el = (feat_src * self.attn_l).sum(dim=-1).unsqueeze(-1)
er = (feat_dst * self.attn_r).sum(dim=-1).unsqueeze(-1)
graph.srcdata.update({'ft': feat_src, 'el': el})
graph.dstdata.update({'er': er})

My question is, if graph.srcdata and graph.dstdata represents data for all src&dst nodes, they should have different shape like [num_src_nodes, hidden_dim] and [num_dst_nodes, hidden_dim], how can they have equal shape?

Hi, you can checkout our previous implementation for better understanding.

If only one tensor is given, the GATConv is applied on an ordinary DGLGraph, where both srcdata and dstdata represent ndata (https://github.com/dmlc/dgl/blob/master/python/dgl/graph.py#L2087-L2095). They must be equal and have the same shape.

When two tensors are given, GATConv is applied on a bipartite graph (this is the case when we train GAT on a large graph in a sampling way), where the number of source nodes and the number of destination nodes might not have equal shape.

1 Like

Since DGLGraph is directional, why srcdata and dstdata both represent ndata? That is somehow elusive.

This is because we would like to unify the case of homograph(ordinary DGLGraph with only one node/edge type) and bipartite graph: in the first case these is only one node type (and thus only one node dict: ndata) where in the second case there are two node types (and thus two completely separate node dicts: srcdata and dstdata).

In other words, when the input is homograph, we regard it as a special case of bipartite graph:

where both sides share the same node data.

So srcdata and dstdata represents ndata for src&dst ntype? I thought they represents ndata for edges’ src&dst nodes :rofl: Now it make sense, but this should be added to the docs since this property easily causes misunderstanding (at least to me).

Yes you are right.
Sorry about the confusion and we will refine the docstring accordingly. @BarclayII let’s take a look.

Agreed. I’m refining docstrings in PR #1420