DESeq2 depends on GeneOrder?

[Michael Love]

The order of the rows of the matrix has no difference on the results. You may have a bug in your code?

> dds <- makeExampleDESeqDataSet()
> idx <- sample(1000, 1000, replace=FALSE)
> dds2 <- dds[idx,]
> res <- results(DESeq(dds))[idx,]
> res2 <- results(DESeq(dds2))
> all.equal(res$log2FoldChange, res2$log2FoldChange)
[1] TRUE

[extended.wobble]

Sorry for my late response. But i think need to bring up the case again.

In addition i need to explain my approach a bit more in detail.
We have 3 WT and 3 treated RNAseq samples that were either counted using HTseq or featureCount. Each count set was separately run through DeSeq2 and resulted in varying fold changes. This happened although the gene-wise raw counts are the same for the two tools used.

Recently, i went another road to exclude errors (still i'm not sure, if i hunt for a bug in my workflow). Taking raw counts produced by featureCount (3x WT, 3x Treatment) once in the original sort order and once randomized fed into DeSeq2 results in varying logFC results as well. I would expect no difference in the logFC irrespective of the order of the input data.

Am i wrong in this assumption?

Thanks a lot.

[extended.wobble]

This is not a bug of DESeq2.

DESeq2 is working with the count table you give it, and you gave it two count tables with a different order on the rows.

The two counting software give you different row order.

Sorry for my imprecise description. The two DESeq outputs were sorted to finally have the same Gene order (by merging the two data frames by GeneID).

[Michael Love]

This is not a bug of DESeq2.

DESeq2 is working with the count table you give it, and you gave it two count tables with a different order on the rows.

The two counting software give you different row order.

[extended.wobble]

Dear all,

currently we are thinking about replacing HTseq count by featureCount from the Subread package. The run time is shortened considerably, while giving the exact same raw counts.

Downstream analysis instead seems to be affected. Running a DESeq2 analysis on the output, results in varying log2fold changes [max( htseq$log2fold - subread$logfold ) != 0 ].
After several tries i could identify the sort order of the geneIDs in the raw counts being the culprit. As soon as i sorted the output of HTseq and featureCount alphabetically by geneID (which resulted in identical lists) DESeq2 computed identical log2fold changes.

Could anyone confirm these results?
Is this a bug or a feature of DESeq2? Is this maybe a consequence of some normalisation (relative-log-expression) approaches undertaken?

Or am i plainly doing anything wrong?

Thanks a lot