Implementation of cluster_wise function

[noriakis]

What is the feature or improvement you would like to see?

Thank you for developing and maintaining this important and useful library.
I would like to propose a function for calculating the network layout based on the cluster information of the nodes.

Use cases for the feature
After applying some clustering algorithms to the nodes, the users can visually inspect the results in the network.

I understand that there is a useful layout function component_wise and layout_components using the components of the graph, but I thought it would be useful if a similar function exits using the cluster information in the graph in the same manner (like in the name cluster_wise?). Similar questions are asked in:
https://stackoverflow.com/questions/23184306/draw-network-and-grouped-vertices-of-the-same-community-or-partition/23185529#23185529
https://stackoverflow.com/questions/16390221/how-to-make-grouped-layout-in-igraph

test <- igraph::random.graph.game(n=100, p=0.01)
V(test)$category <- sample(1:5, 100, replace=TRUE)
test %>%
  add_layout_(in_circle(), cluster_wise(cluster_id="category")) %>%
  plot(vertex.color=as.numeric(V(test)$category),
       vertex.size=5, vertex.label=V(test)$category)

It seems there are none after searching the codebase and I made this issue. I apologize if this kind of feature is already available by combining functions or if this is an unwanted feature.

If I may, I would like to make a pull request for the feature.
noriakis@d7c63d4

References
None

[szhorvat]

Let me check if I understand what you are requesting:

• This function will lay out subgraphs corresponding to each specified community individually
• It will then merge these layout without taking into account the connections between the communities

I am not in favour of including such a feature in igraph because:

• Since connections between communities are not taken into account, the layout will typically be quite poor.
• The layout obtained this way does not actually reveal information about any community structure.
• For those who really want this anyway, it can already be accomplished with merge_coords()

There are more advanced layout methods that can take communities into account, and it would make sense to implement those. One example is hierarchical edge bundling. But this naive approach doesn't really produce good results.

---

The reason for the existence of layout_components() is that most layout algorithms were not designed to be able to handle disconnected graphs. The proper approach is to lay out each weakly connected component separately, then merge the layouts by some method. Currently igraph only has a rudimentary support for this, but we hope to be able to do more in the future.

To be clear, the ultimate decision about this it with @krlmlr, not me.

[noriakis]

Thank you very much for your detailed answer.

Let me check if I understand what you are requesting:

• This function will lay out subgraphs corresponding to each specified community individually
• It will then merge these layout without taking into account the connections between the communities

Yes, that is what I was considering. The initial reason was I thought it would be useful to visually examine how nodes with already established labels (cluster information) relate to other nodes on the network with the known relationship by explicitly disjointing them (like in the visualization of the gene regulatory network with information on the genes).

However, as you stated, this indeed performs poorly and can be already accomplished with merge_coords().

I am not in favour of including such a feature in igraph because:

• Since connections between communities are not taken into account, the layout will typically be quite poor.
• The layout obtained this way does not actually reveal information about any community structure.
• For those who really want this anyway, it can already be accomplished with merge_coords()

Thank you for your clarification on the points that this is not an expected feature in igraph, and I completely agree with these. In particular, I am very convinced by the reason for the existence of layout_components().

Again, thank you for taking the time to consider this issue and for maintaining this important project.