Expression data in the multi-set format (see checkSets). A vector of lists, one per set. Each set must contain a component data that contains the expression data, with rows corresponding to samples and columns to genes or probes.

optional observation weights in the same format (and dimensions) as multiExpr. These weights are used for correlation calculations with data in multiExpr.

If multiExpr contain missing data, this argument can be used to supply the expression data with missing data imputed. If not given, the impute.knn function will be used to impute the missing data.

A vector (numeric, character or a factor) giving module labels for each variable (gene) in multiExpr.

The label (value in labels) that represents unassigned genes. Module of this label will not enter the module eigengene clustering and will not be merged with other modules.

A single list of class NetworkOptions giving options for network calculation for all of the networks, or a multiData structure containing one such list for each input data set.

A list of class ConsensusTree specifying the consensus calculation.

Minimum number of genes in a module. Modules that have fewer genes (after trimming) will be removed (i.e., their genes will be given the unassigned label).

a number between 0 and 1. If a detected module does not have at least minModuleKMESize genes with consensus eigengene connectivity at least minCoreKME, the module is disbanded (its genes are unlabeled).

see minCoreKME above.

genes whose consensus eigengene connectivity to their module eigengene is lower than minKMEtoStay are removed from the module.

logical: should imputation be used for module eigengene calculation? See moduleEigengenes for more details.

logical: should errors in calculations be trapped?

Logical: should module eigengene similarities be calibrated before calculating the consensus? Although calibration is in principle desirable, the calibration methods currently available assume large data and do not work very well on eigengene similarities.

Dendrogram cut height for module merging.

Logical: should the pruning and merging process be iterated until no changes occur? If FALSE, only one iteration will be carried out.

Logical: should garbage be collected after some of the memory-intensive steps?

Logical: should certain intermediate results be returned? These include labels and module merging information at each iteration (see return value).

integer level of verbosity. Zero means silent, higher values make the output progressively more and more verbose.

indentation for diagnostic messages. Zero means no indentation, each unit adds two spaces.

The resulting module labels

A list. The first component, named originalLabels, contains a copy of the input labels. The following components are named Iteration.1, Iteration.2 etc and contain, for each iteration, components prunedLabels (the result of pruning in that iteration) and mergeInfo (result of the call to hierarchicalMergeCloseModules in that iteration).