Paper: CoRe-GD: A Hierarchical Framework for Scalable Graph Visualization with GNNs (ICLR-2024)

Reviewer comment (Theory):
The motivation of the hierarchical optimization and positional rewiring is not clearly introduced. I would recommend the authors discuss the computational complexity among the proposed CoReGD, DeepGD, and SmartGD. In addition, the authors should introduce why positional rewiring is important in hierarchical optimization.

Author response:
Thanks for the suggestion. We added Table 3 and a small paragraph to introduce the baselines and their computational complexity. We also improved Section 3 and now point out more clearly why the positional rewiring is useful.

Reviewer comment (Presentation):
I found it a bit hard to follow the method section. A diagram of the whole algorithm should be carefully introduced in this section, which can make the readers clearer to the proposed algorithm before diving into the details. It is difficult to understand the pipeline of CoReGD from Figure 2, e.g., h_1^1, h_1^l, h_1^{c+1}.

Author response:
We admit that Figure 2 could have been better for introducing the algorithm. We updated the manuscript and combined Figure 2 and 3 to serve the purpose you mentioned. We also added textual descriptions to make the overview more clear.  
The embeddings h_1^1, etc., are part of the figure as they also appear in the pseudocode in Appendix A.2. This makes it possible to align both the figure and the pseudocode to better understand how embeddings are passed exactly between modules.

Reviewer comment (Evaluation):
An efficiency-stress curve would be great to understand relative runtimes and stress performances of the different methods in this landscape, as the authors' individual experiments suggest that CoreGD is the best performing and fastest.

Author response:
We added plots in Appendix A.7.3 to show this. These show that CoRe-GD is indeed Pareto-optimal regarding runtime and layout quality.

Reviewer comment (Experiments):
3.1 suggests the efficiency and effectiveness for CoreGD is largely influenced by the input feature choice. Some of the features that offer high discriminability might be difficult/expensive to compute for large graphs (e.g. Laplacian PEs or beacons).

Author response:
This is a good observation. First of all, we show that the features we use can be computed in sub-quadratic time. Of course, practical runtimes can still vary, but we want to point out that the computation for initial features only needs to be done for the coarsest graph, which we can bound by a maximum size (and thus assume to be constant). To back this up empirically, we compared both CoRe-GD with the coarsening hierarchy and without any coarsening in Figure 5. We can observe that for a graph size of around 12000, an inflection point is reached where the variant with coarsening becomes faster than the one without, exactly because the feature computation is becoming more and more expensive. As mention in the paper, this is one major advantage of the coarsening.

Reviewer comment (Experiments):
The random noise addition step in 3.2 is interesting: this would mean the output drawing is stochastic, I guess. How sensitive are output drawing configurations to the noise introduced here?

Author response:
Indeed, all presented algorithms used as baselines in the paper produce randomized results. For CoRe-GD, this is also the case because it uses randomized features for nodes. To judge the impact of different training runs and executions, we provide the standard variation for all results in the paper. We observe that they are rather small and comparable to the classical algorithms. 
To further underline this, we computed the mean and standard deviation using only one model for datasets (which we provide with the code) over 5 runs. The results are as follows:

| Rome  | Zinc  | MNIST  | CIFAR10  | PATTERN  | CLUSTER  | suitesparse |
|---|---|---|---|---|---|---|
| 233.25 $\pm$ 0.16 | 5.10 $\pm$ 0.02  |  129.07 $\pm$ 0.02 | 262.66 $\pm$ 0.06  | 3065.79 $\pm$ 0.05  |  2827.00 $\pm$ 0.02 | 42396.23 $\pm$ 66.12 |

We can observe that the standard deviation is similar to or lower than when using multiple trained models. So, on one hand, the training is relatively stable and produces similar results over different training runs, and on the other, the trained models themselves show little variation when used multiple times with different random seeds.
We want to point out that the drawings can still look different in ways that do not affect stress, e.g., the graph could be rotated. This is usually not a problem in practice and something that applies to all other methods, too.

Reviewer comment (Writing):
Section 3's overview of Core-GD is quite hard to understand. Some design choices aren't obvious to the reader: (i) why do we need two convolutions (Conv_E and Conv_R), (ii) what's the purpose of the rewiring module? How exactly does the GRU fit in? Structuring this section with equations which the reader can follow from inputs to position coordinates would have probably helped understand the sequence of operations.

Author response:
Thanks for pointing this out. We improved the writing in Section 3 and redesigned the overview figure to make this more clear. We also want to address the two questions here: (i) Conv_E and Conv_R work on different graph topologies, the first on the original graph and the second on the rewired edges. As these two have distinct characteristics, we decided to use two different parametrizations. (ii) The rewiring is done to let nodes that are not close to each other in the graph topology but close in the drawing directly exchange information with each other. This is important because nodes in close proximity (in the drawing) can have a large impact on the stress loss without knowing about each other. As we mention in the paper, previous work showed that the GRU works well for recurrent GNNs like ours with many applications of the same recurrent layer (possibly hundreds). The ablation study testing different convolutions in A.4 empirically validates this. Regarding formulas, we tried to pack the main part of the paper as densely as possible. Figure 2 contains the names of all embeddings used in the pseudocode we provide in Appendix A.2. This makes it possible to line up the figure with the pseudocode and helps to understand the sequence of operations from start to finish. A formula for the GRU convolution is also presented.

Reviewer comment (Evaluation):
Table 1 suggests that Core-GD seems to achieve similar performance to DeepGD -- I'm not familiar with the differences with these methods, but some discussion regarding the speed advantages of CoreGD compared to DeepGD would be helpful to contextualize the added value of using the algorithm proposed by the authors.

Author response:
One main goal of CoRe-GD is to remain scalable by running in sub-quadratic time. This is the big distinguishing factor between CoRe-GD and DeepGD. To make this more clear, we added more discussion on runtimes of existing algorithms and other properties to Table 3 in the Appendix. As we show in our scaling study, the faster runtime of CoRe-GD allows it to run on graphs that are much bigger than those that DeepGD can handle.

Reviewer comment (Presentation):
Some training details are put in the appendix. I found that after reading the main body of the paper, I couldn’t understand how the framework is applied for training and serving. I think the writing order of the paper needed to be improved. And the figure 2 is relatively hard to understand. Please give a more clear illustration about the graph after being processed by each module in your framework.

Author response:
Thanks for the suggestion. We combined Figures 2 and 3 and gave them an overhaul with newly added textual descriptions and more depictions of the graph between the different processing steps to make them easier to understand. The writing in Section 3 has also been improved to make the execution clear. The main body now gives a clear overview of the algorithm, while detailed pseudocode for both training and inference is given in Appendix A.2.

Reviewer comment (Experiments):
The work is related with graph condensation or graph summarization, and some baselines about graph condensation or summarizarion should be included.

Author response:
Graph condensation and summarization (in the context of graph learning, we assume this is what you refer to, please correct us if we are wrong) are concerned with reducing the size of a graph while maintaining important information, usually based on label information and the graph structure. As a byproduct of the graph being reduced, this might lead to more pleasing layouts once visualized. On the other hand, the graph drawing task we are considering finds a stress-optimized spatial embedding for the original graph. These tasks are inherently different, and we do not see how a meaningful comparison with baselines for graph condensation and summarization to our method can be done. 
We could also not find more information on a further relation between graph drawing and condensation/summarization in the literature. If there is a comparison that you have in mind which would make sense for our task, then please let us know. Otherwise, if this was your main concern, then we would be happy if you would consider increasing your score.