Galaxy | (sandbox for testing) | Tool Preview

Differential_Count (version 0.28)
Use the HTSeq based count matrix preparation tool to create these matrices from BAM/SAM files and a GTF file of genomic features
Supply a meaningful name here to remind you what the outputs contain
Leave blank if no pairing, but eg if data from sample id A99 is in columns 2,4 and id C21 is in 3,5 then enter 'A99,C21,A99,C21'
May be a good or a bad idea depending on the biology and the question. EG 0.3 = sparsest 30% of contigs with at least one read are removed before analysis
May be a good or a bad idea depending on the biology and the question. This was the old default. Quantile based is available as an alternative
edgeR uses a negative binomial model and seems to be powerful, even with few replicates
10 = edgeR default. Use a larger value to 'smooth' small samples. See edgeR docs and note below
Use ordinary, anscombe or deviance robust deviance estimates
DESeq2 is an update to the DESeq package. It uses different assumptions and methods to edgeR
Voom uses counts per million and a precise transformation of variance so count data can be analysed using limma
Conventional default value of 0.05 recommended
Use fdr or bh typically to control for the number of tests in a reliable way

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