mclcm(1)

πŸ“¦
version 22-282 Β· 2 versions
  • 22-282 Β· debian bookworm, debian trixie, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 14-137 Β· ubuntu jammy
, in debian bookworm, debian trixie, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ mclcm(1) ✨ β€” hierarchical clustering of graphs with mcl πŸ’…

okay bestie, gather round 🫢 this is mclcm and she builds hierarchies of clusters on top of your graphs using mcl. it's giving tree energy, it's giving nested-cluster main character, and yes it is literally the tool you want when one flat clustering isn't enough. 🌸


πŸŽ€ NAME πŸŽ€

mclcm β€” hierarchical clustering of graphs with mcl


πŸ¦‹ SYNOPSIS πŸ¦‹

mclcm <-|fname> [mclcm-options] [-- "mcl options"*]

and the lil' example runs, copied character for character because we do not play with syntax around here:

mclcm <-|fname> -a "-I 4 --shadow=vl"
mclcm <-|fname> -a "-I 3" -- "-I 5"
mclcm <-|fname> -a "-I 3" -b1 "" -- "-ph 3 --shadow=vl -I 5"

and the big long full-form one, so you can see every single knob in one breath:

mclcm <-fname> [--contract (contraction mode)] [--dispatch (dispatch mode)] [--integrate (integrate mode)] [--subcluster (subcluster mode)] [-a <opts> (shared mcl options)] [-b1 <opts> (dedicated base 1 mcl options)] [-b2 <opts> (dedicated base 2 mcl options)] [-tf spec (apply tf-spec to input matrix)] [-c <fname> (input clustering)] [-n <num> (iteration limit)] [--root (ensure universe root clustering)] [-cone <fname> (nested cluster stack file)] [-stack <fname> (expanded cluster stack file)] [-coarse <fname> (coarsened graphs file)] [-write (stack,cone,coarse,steps)] [-write-base <fname> (write base matrix)] [-stem <str> (prefix for all outputs)] [--mplex=y/n (write clusterings separately)] [-annot str (dummy annotation option)] [-h (print synopsis, exit)] [--apropos (print synopsis, exit)] [--version (print version, exit)] [-q spec (log levels)] [-z (show default shared options)] [-- "mcl options"*]

🌈 DESCRIPTION 🌈

so the mclcm options can be followed by a bunch of trailing arguments. those trailing arguments gotta be separated from the mclcm options by the separator --. normally each trailing argument should be a set of zero, one, or more mcl arguments wrapped in quotes or double quotes so they get grouped together like a little squad. πŸ“Ž these arguments get passed to the successive stages of hierarchical clustering, and they get combined with the default options. and here's the tea: if an option shows up in both the default options list and a trailing options list, the trailing one wins and overrides the default. periodt.

careful though β€” when the --integrate option is specified, the trailing arguments must be names of files containing mcl clusterings. see further below bestie πŸ‘‡

mclcm has four major modes of operation, namely contraction (the default), integration, dispatch, and subcluster. each mode is described a lil' below. but lowkey note this: dispatch mode is not the best mode to use for hierarchical clustering. it's mostly useful to generate multiple mcl clusterings in a single run. πŸ’€

in all modes mclcm will generate a file, by default called mcl.cone. this is a representation of a hierarchical clustering that is particular to mcl. it can be converted to newick format like this:

mcxdump -imx-tree mcl.cone --newick -o NEWICKFILE

OR

mcxdump -imx-tree mcl.cone --newick -o NEWICKFILE -tab TABFILE

in that last example, TABFILE should be a file containing a mapping from mcl labels to application labels. refer to mcxio(5) for more info about tab files and mcl input/output formats. πŸ“š


✨ OPTIONS ✨

  • --contract β€” (repeated contraction mode) this is the default mode of operation, the one she wakes up in. at each successive step of constructing the hierarchy on top of the first level mcl clustering, mclcm uses a matrix derived from the input matrix and the last computed clustering to compute a contracted graph. the contracted graph is a graph where the nodes represent the clusters of the last clustering. the matrix derived from the input graph that is used to construct the contracted graph is called the base matrix. the base matrix can be either the start matrix or the expansion matrix. the start matrix is the input matrix after transformations have been applied to it (if any). the expansion matrix is the first expanded matrix of some mcl process applied to the input graph.

by default the base matrix is constructed from either the start matrix or the expansion matrix obtained from the first mcl process. it's possible to use a start matrix derived from special purpose mcl transformation parameters (such as -ph and -tf) or an expansion matrix derived from a special purpose mcl process. the -b1 and -b2 parameters provide the interfaces to this functionality. πŸŽ›οΈ

you are advised to start with a high inflation value for the input graph and to use shadowing, e.g. include --shadow=vl in the -a argument. this generally leads to hierarchies that are better balanced. shadowing is a transformation where nodes are added to the graph, preventing relatively distant nodes from unwanted chaining. for more information refer to the mcl manual. the invocations in SYNOPSIS are a good starting point. πŸ‘‘
  • --dispatch β€” (different mcl processes) in this mode each trailing argument is specified as a set of options to pass to an mcl process. for each trailing argument an mcl process is thus computed. the set of resulting clusterings is integrated into a hierarchy. 🧩
  • --integrate β€” (existing clusterings) this mode is similar to dispatch mode. the difference is that with this option mclcm simply integrates a set of already existing clusterings. each trailing argument must be the name of a file containing a clustering. the set of clusterings thus specified is integrated into a hierarchy. πŸ«‚
  • --subcluster β€” (repeated sub-clustering) in this mode each trailing argument specifies a set of options to pass to an mcl process. the second clustering process is applied to the graph of components induced by the first clustering, resulting in a further subdivision of the first clustering. this approach is repeated with each further trailing argument. with this approach, the first clustering will be the most coarse clustering. hence, subsequent trailing arguments will typically specify increasingly higher inflation values, pre-inflation values, and optionally more stringent transformation parameters in order to achieve further subdivisions. πŸͺ†
  • -a <opts> β€” (shared mcl options) use this to change and/or set the default mcl options for all iterations. use quotes if necessary. example of usage: -a "-I 5".
  • -b1 <opts> β€” (dedicated base 1 mcl options) this will apply the mcl options opts to the input matrix. the resulting start matrix is used as the base matrix for constructing contracted graphs. 🌱
  • -b2 <opts> β€” (dedicated base 2 mcl options) this will apply the mcl options opts to the input matrix and compute the first iterand of the corresponding mcl process. the first iterand, aka the expansion matrix, is used as the base matrix for constructing contracted graphs. 🌿
  • -tf <tf-spec> β€” (transform input matrix values) transform the input matrix values according to the syntax described in mcxio(5). πŸ”„
  • -c <fname> β€” (input clustering) the hierarchical clustering process will be kicked off by the clustering found in <fname>. πŸš€
  • -n <num> β€” (iteration limit) this puts an upper bound to the number of contractions that will be performed. βœ‹
  • --root β€” (ensure universe root clustering) in case the graph consists of different connected components, the last clustering computed by the mclcm process will correspond with those connected components. this option simply adds an artificial clustering where all nodes have been joined into a single cluster. 🌍
  • -cone <fname> β€” (nested cluster stack file) file to write the nested cluster stack to. the nested cluster stack contains a sequence of clusterings, each written as an MCL matrix. the first (bottom) clustering is a clustering of the nodes in the input graph. each subsequent clustering is a clustering where the nodes are the clusters of the previous clustering. mcxdump can dump this format if the file name is given as the -imx-stack option. the explanation for the cone/stack discrepancy is simple: to mcxdump the contents are simply a stack of matrices. it does not care whether the stack is cone shaped, cylindrical, or yet another shape. 🍦
  • -stack <fname> β€” (expanded cluster stack file) file to write the expanded cluster stack to. the expanded cluster stack is similar to the nested cluster stack except that each cluster lists all the nodes in the input graph it contains. mcxdump can dump this format if the file name is given as the -imx-stack option. πŸ₯ž
  • -coarse <fname> β€” (coarsened graphs file) file to write the sequence of coarsened graphs to. each clustering induces a coarsened graph where the nodes represent the clusters and an edge between two nodes represents the connectivity between the corresponding two clusters. the computation of this connectivity takes into account all edges between the two clusters in the original graph. πŸ•ΈοΈ
  • -write <tag> β€” (select output modes) use this option to explicitly specify all of the output types you want written in a comma-separated string. <tag> may contain any of the strings stack, cone, coarse, steps. the current default is to write all of these except coarse. the latter dumps the intermediate coarsened (aka contracted) graphs to a single file. πŸ“
  • -write-base <fname> β€” (write base matrix) write the base matrix to file. this can be useful for debugging expectations. πŸ”
  • -stem <str> β€” (prefix for all outputs) all output files share the same prefix. the default is mcl and can be changed with this option. 🏷️
  • --mplex=y/n β€” (write clusterings separately) if turned on each clustering is written in a separate file. the first clustering is written to the file <stem>.3 where <stem> is determined by the -stem option. for each subsequent clustering the index is incremented by two, so clusterings are written to files for which the name ends with an odd index. πŸ”’
  • -annot str β€” (dummy annotation option) mclcm writes the command line with which it was invoked to the output file (either of the cone or stack files). use this option to include any additional information. mclcm does nothing with this option except copying it as just described. πŸ™ˆ
  • -q spec β€” (log levels) set the quiet level. read tingea.log(7) for syntax and semantics. 🀫
  • -z β€” (show default shared options) show the default mcl options. these are used for each mcl invocation as successively applied to the input graph and succeeding contracted graphs. πŸ‘€
  • -h, --apropos, --version β€” as listed in SYNOPSIS: print synopsis and exit; print synopsis and exit; print version and exit. πŸ’Œ

πŸ‘‘ AUTHOR πŸ‘‘

Stijn van Dongen.


🌸 SEE ALSO 🌸

mclfamily(7) for an overview of all the documentation and the utilities in the mcl family.


okay that's the whole page bestie, and it's giving πŸ’– this was mclcm from mclcm 22-282, dated 9 Oct 2022 β€” go build a hierarchy, you absolute icon, and remember: shadowing is your friend, quotes are your bestie, and the trailing args go after --. slay πŸŽ€βœ¨πŸ¦‹

πŸ“¦ where this page comes from