What it does
Allows short read sequence counts from controlled experiments to be analysed for differentially expressed genes. Optionally adds a term for subject if not all samples are independent or if some other factor needs to be blocked in the design.
Input
Requires a count matrix as a tabular file. These are best made using the companion HTSeq based counter Galaxy wrapper and your fave gene model to generate inputs. Each row is a genomic feature (gene or exon eg) and each column the non-negative integer count of reads from one sample overlapping the feature.
The matrix must have a header row uniquely identifying the source samples, and unique row names in the first column. Typically the row names are gene symbols or probe ids for downstream use in GSEA and other methods. They must be unique and R names or they will be mangled - please read the fine R docs for the rules on identifiers.
Specifying comparisons
This is basically dumbed down for two factors - case vs control.
More complex interfaces are possible but painful at present. Probably need to specify a phenotype file to do this better. Work in progress. Send code.
If you have (eg) paired samples and wish to include a term in the GLM to account for some other factor (subject in the case of paired samples), put a comma separated list of indicators for every sample (whether modelled or not!) indicating (eg) the subject number or A list of integers, one for each subject or an empty string if samples are all independent. If not empty, there must be exactly as many integers in the supplied integer list as there are columns (samples) in the count matrix. Integers for samples that are not in the analysis must be present in the string as filler even if not used.
So if you have 2 pairs out of 6 samples, you need to put in unique integers for the unpaired ones eg if you had 6 samples with the first two independent but the second and third pairs each being from independent subjects. you might use 8,9,1,1,2,2 as subject IDs to indicate two paired samples from the same subject in columns 3/4 and 5/6
Methods available
You can run 3 popular Bioconductor packages available for count data.
edgeR - see edgeR for details
VOOM/limma - see limma_VOOM for details
DESeq2 - see DESeq2 for details
and optionally camera in edgeR which works better if MSigDB is installed.
Outputs
Some helpful plots and analysis results. Note that most of these are produced using R code suggested by the excellent documentation and vignettes for the Bioconductor packages invoked. The Tool Factory is used to automatically lay these out for you to enjoy.
Note on Voom
The voom from limma version 3.16.6 help in R includes this from the authors - but you should read the paper to interpret this method.
This function is intended to process RNA-Seq or ChIP-Seq data prior to linear modelling in limma.
voom is an acronym for mean-variance modelling at the observational level. The key concern is to estimate the mean-variance relationship in the data, then use this to compute appropriate weights for each observation. Count data almost show non-trivial mean-variance relationships. Raw counts show increasing variance with increasing count size, while log-counts typically show a decreasing mean-variance trend. This function estimates the mean-variance trend for log-counts, then assigns a weight to each observation based on its predicted variance. The weights are then used in the linear modelling process to adjust for heteroscedasticity.
In an experiment, a count value is observed for each tag in each sample. A tag-wise mean-variance trend is computed using lowess. The tag-wise mean is the mean log2 count with an offset of 0.5, across samples for a given tag. The tag-wise variance is the quarter-root-variance of normalized log2 counts per million values with an offset of 0.5, across samples for a given tag. Tags with zero counts across all samples are not included in the lowess fit. Optional normalization is performed using normalizeBetweenArrays. Using fitted values of log2 counts from a linear model fit by lmFit, variances from the mean-variance trend were interpolated for each observation. This was carried out by approxfun. Inverse variance weights can be used to correct for mean-variance trend in the count data.
Author(s)
Charity Law and Gordon Smyth
References
Law, CW (2013). Precision weights for gene expression analysis. PhD Thesis. University of Melbourne, Australia.
Law, CW, Chen, Y, Shi, W, Smyth, GK (2013). Voom! Precision weights unlock linear model analysis tools for RNA-seq read counts. Technical Report 1 May 2013, Bioinformatics Division, Walter and Eliza Hall Institute of Medical Reseach, Melbourne, Australia. http://www.statsci.org/smyth/pubs/VoomPreprint.pdf
See Also
A voom case study is given in the edgeR User's Guide.
vooma is a similar function but for microarrays instead of RNA-seq.
*old rant on changes to Bioconductor package variable names between versions*
The edgeR authors made a small cosmetic change in the name of one important variable (from p.value to PValue) breaking this and all other code that assumed the old name for this variable, between edgeR2.4.4 and 2.4.6 (the version for R 2.14 as at the time of writing). This means that all code using edgeR is sensitive to the version. I think this was a very unwise thing to do because it wasted hours of my time to track down and will similarly cost other edgeR users dearly when their old scripts break. This tool currently now works with 2.4.6.
Note on prior.N
http://seqanswers.com/forums/showthread.php?t=5591 says:
prior.n
The value for prior.n determines the amount of smoothing of tagwise dispersions towards the common dispersion. You can think of it as like a "weight" for the common value. (It is actually the weight for the common likelihood in the weighted likelihood equation). The larger the value for prior.n, the more smoothing, i.e. the closer your tagwise dispersion estimates will be to the common dispersion. If you use a prior.n of 1, then that gives the common likelihood the weight of one observation.
In answer to your question, it is a good thing to squeeze the tagwise dispersions towards a common value, or else you will be using very unreliable estimates of the dispersion. I would not recommend using the value that you obtained from estimateSmoothing()---this is far too small and would result in virtually no moderation (squeezing) of the tagwise dispersions. How many samples do you have in your experiment? What is the experimental design? If you have few samples (less than 6) then I would suggest a prior.n of at least 10. If you have more samples, then the tagwise dispersion estimates will be more reliable, so you could consider using a smaller prior.n, although I would hesitate to use a prior.n less than 5.
From Bioconductor Digest, Vol 118, Issue 5, Gordon writes:
Dear Dorota,
The important settings are prior.df and trend.
prior.n and prior.df are related through prior.df = prior.n * residual.df, and your experiment has residual.df = 36 - 12 = 24. So the old setting of prior.n=10 is equivalent for your data to prior.df = 240, a very large value. Going the other way, the new setting of prior.df=10 is equivalent to prior.n=10/24.
To recover old results with the current software you would use
estimateTagwiseDisp(object, prior.df=240, trend="none")
To get the new default from old software you would use
estimateTagwiseDisp(object, prior.n=10/24, trend=TRUE)
Actually the old trend method is equivalent to trend="loess" in the new software. You should use plotBCV(object) to see whether a trend is required.
Note you could also use
prior.n = getPriorN(object, prior.df=10)
to map between prior.df and prior.n.
Attributions
edgeR - edgeR
VOOM/limma - limma_VOOM
DESeq2 - DESeq2 for details
See above for Bioconductor package documentation for packages exposed in Galaxy by this tool and app store package.
Galaxy (that's what you are using right now!) for gluing everything together
Otherwise, all code and documentation comprising this tool was written by Ross Lazarus and is licensed to you under the LGPL like other rgenetics artefacts