-
Notifications
You must be signed in to change notification settings - Fork 2
Community Detection
Understanding how GraphBrew uses Leiden community detection for graph reordering.
Community detection finds densely connected groups of vertices in a graph. Vertices within a community have many connections to each other and fewer connections to vertices outside.
Before: After Leiden:
1---2 Community A: {1,2,3}
|\ /| Community B: {4,5,6}
| X |
|/ \|
3 4---5
|\ /|
| X |
|/ \|
6
When vertices from the same community are numbered consecutively:
- Their data is contiguous in memory
- Cache lines are used efficiently
- Fewer cache misses during graph traversal
Original IDs: [1, 4, 2, 5, 3, 6] ← Community members scattered
Reordered: [1, 2, 3, 4, 5, 6] ← Community A then Community B
Graph algorithms typically process vertices and their neighbors:
- PageRank: Updates vertex scores based on neighbors
- BFS: Explores neighbors in order
- Triangle Counting: Checks edges between neighbors
When neighbors are close in memory, these operations are faster.
Leiden improves upon the popular Louvain algorithm with:
- Guaranteed connected communities
- Better quality (higher modularity)
- Faster convergence in most cases
- Move Phase: Greedily move vertices to improve modularity
- Refinement Phase: Split communities to ensure connectivity
- Aggregation Phase: Create super-graph of communities
- Repeat until no improvement
Modularity measures community quality:
Where:
-
$A_{ij}$ = edge between i and j -
$k_i$ = degree of i -
$m$ = total edges -
$\delta(c_i, c_j)$ = 1 if same community
Higher modularity = better community structure.
GraphBrew includes a full Leiden implementation in bench/include/external/leiden/:
leiden/
├── leiden.hxx # Main Leiden algorithm (LeidenOptions struct)
├── louvain.hxx # Louvain base implementation
├── Graph.hxx # Graph representation
├── csr.hxx # CSR-native operations
├── dfs.hxx # DFS traversal utilities
├── bfs.hxx # BFS traversal utilities
├── batch.hxx # Batch processing support
├── rak.hxx # Random neighbor sampling
├── properties.hxx # Graph property computation
└── ... # Additional utilities
Leiden is used internally by Leiden-based algorithms:
| Algorithm | Uses Leiden | Format |
|---|---|---|
| LeidenOrder (15) | ✓ | -o 15:resolution |
| GraphBrewOrder (12) | ✓ | -o 12:variant:final_algo:resolution |
| AdaptiveOrder (14) | ✓ | -o 14[:_[:_[:_[:selection_mode[:graph_name]]]]] |
=== Leiden Community Detection ===
Graph: N nodes, M edges
Resolution: 1.0
Iterations: ...
Communities found: ...
Modularity: ...
Community sizes:
Community 0: ... nodes
Community 1: ... nodes
...
Controls community granularity:
| Resolution | Effect | Best For |
|---|---|---|
| < 1.0 | Fewer, larger communities | True community detection |
| 1.0 | Default balance | General use |
| > 1.0 | More, smaller communities | Cache locality / graph reordering |
Key insight: Higher resolution produces smaller, cache-sized communities → better locality → faster algorithms, despite lower modularity.
See AdaptiveOrder-ML#parameters for the auto-resolution formula and dynamic/adaptive resolution details.
Defaults from reorder::ReorderConfig: maxIterations=10, maxPasses=10. Usually converges in 2-5 iterations.
Hierarchical dendrogram-like ordering:
- Detect communities using Leiden (multi-pass)
- Sort vertices by all passes (coarsest to finest)
- Within same sub-community: sorted by degree (descending)
This achieves RabbitOrder-like locality using Leiden's community structure.
Sort key: (pass_N, pass_N-1, ..., pass_0, degree)
Result: Vertices in same sub-sub-community are adjacent
Fast CSR-native Leiden + per-community reordering. See Reordering-Algorithms#12-graphbreworder for variant table, resolution modes, and usage examples.
Leiden-based reordering benefits graphs with clear community structure (higher modularity). Graphs with weak or no community structure (road networks, grids, random graphs) see little benefit. Run the pipeline on your target graphs to measure actual improvements.
./bench/bin/pr -f graph.el -s -o 14 -n 1
Leiden: N communities, modularity X.XXXX
| Range | Interpretation |
|---|---|
| < 0.1 | No community structure |
| 0.1 - 0.3 | Weak structure |
| 0.3 - 0.5 | Moderate structure |
| 0.5 - 0.7 | Strong structure |
| > 0.7 | Very strong structure |
For each community, GraphBrew computes structural features (num_nodes, num_edges, density, avg_degree, degree_variance, hub_concentration, clustering_coeff, modularity). See Code-Architecture for the CommunityFeatures struct in reorder_types.h.
| Method | Quality | Speed | Connected Communities |
|---|---|---|---|
| GVE-Leiden | ★★★★★ | ★★★★ | Yes |
| Louvain (RabbitOrder) | ★★★★ | ★★★★★ | No |
| Infomap | ★★★★★ | ★★★ | No |
| Label Prop | ★★★ | ★★★★★ | No |
Why Leiden over Louvain? Leiden's refinement phase prevents bad merges, producing higher modularity with connected communities.
Ref: Traag et al. (2019). From Louvain to Leiden. Scientific Reports 9, 5233.
- Reordering-Algorithms - All reordering techniques
- AdaptiveOrder-ML - ML-based algorithm selection
- Graph-Benchmarks - Available benchmarks