Algorithms/Community Detection Procedures

This family is about partitioning, labeling, or evaluating graph structure so that users can reason about groups, roles, overlaps, or boundaries. The important point is that these procedures are not interchangeable. They answer different questions.

Consumer View

Ask yourself which question you are actually trying to answer:

Which nodes belong together as one main partition? Start with leiden or louvain.
Do I need several resolution levels? Use hierarchical_leiden.
Do nodes belong to several groups at once? Use slpa, sllpa, or bigclam.
Is this graph really about roles and interaction patterns, not dense communities? Use the stochastic block partition family.
Is movement or flow the key idea? Use infomap.
Do I need to score a partition rather than create one? Use modularity_metric or conductance.
Am I solving a partitioning or constraint problem rather than community discovery? Look at k1coloring and maxkcut.

Conceptual Comparison

Family	Best when	Not ideal when
`louvain`	you need a fast, practical baseline partition	you need the cleanest connected communities
`leiden`	partition quality and internal connectedness matter	you only need the cheapest first-pass answer
`hierarchical_leiden`	you need coarse and fine communities	one flat partition is enough
`label_propagation`	speed and quick exploration matter	stability and defensibility matter
`slpa` / `sllpa` / `bigclam`	overlap is real and one node can belong to several groups	downstream systems require one clean label only
`infomap`	flow, movement, or communication is the real story	the graph is better understood as dense neighborhoods
block partition variants	roles and interaction patterns matter more than dense communities	users expect communities in the everyday sense
`modularity_metric` / `conductance`	you already have candidate communities and need validation	you still need the communities themselves
`k1coloring` / `maxkcut`	you need separation, constraints, or cuts	you want cohesive communities

Real Selection Guidance

Choose leiden over louvain when the output will be used in product decisions, investigations, or dashboards where disconnected communities would damage trust.
Choose louvain when you need a strong practical baseline for a large graph and you are willing to inspect the results before operationalizing them.
Choose label_propagation when you need something cheap enough for interactive exploration or broad what-if comparisons.
Choose slpa, sllpa, or bigclam when forcing a single label would erase important multi-membership structure such as shared services, mixed-interest users, or bridge accounts.
Choose infomap when paths, flow, or traffic make more sense than density. Examples: clickstreams, mobility, message routes, or communication networks.
Choose block-model procedures when you care about roles like broker, sink, hub, supplier, coordinator, or consumer, not just “communities.”

How To Use These Pages

Each algorithm page in this folder gives:

a plain-language explanation
a conceptual explanation of the mathematical or structural idea
a comparison with nearby algorithms so users can make a real choice
a focused advanced example that combines graph, time, document, and vector-style features
concrete use cases and concrete limitations

Pages: