Wald test after RUVSeq for DESeq?

[chrarnold]

I have a question regarding the RUVseq batch removal in combination with DESeq. The code uses a LRT while specifying a reduced model that contains the RUVSeq components using a glmGamPoi fitType.

Would the default Wald test ala DESeq(dds) also suffice here, without specifying anything non-default (except the updated design formula that includes the hidden batches, of course), or the LRT is prefered? If so, what is the reason? Maybe a sentence could be added in the code for this, might be helpful generally.

Thanks, Christian

[mikelove]

hi Christian,

Mostly the glmGamPoi is desired for speed, and glmGamPoi requires LRT.

I think the default would be fine as well. What I've mentioned on the support site -- there can sometimes be a breakdown of the Wald test for certain contrasts with complex designs and infinite LFC -- all zero in one or more groups and positive counts in the other groups. And in these cases either LRT or using our shrinkage estimators (lfcShrink) outperform the Wald statistic in terms of ranking robust signals compared to those driven by a few outliers. It doesn't always seem to be a problem, but seems to occur when there is also high dispersion (within group variability). Here with the extra explanatory factors, the within-group dispersion may be lowered relative to what it would be with only the condition variable.

[chrarnold]

Hi Mike, thanks for the informative reply, right, I forgot already about the recent speed improvements with the glmGamPoi model from Constantin. You mention some very interesting edge cases. I wonder whether this can somehow be coded up in a way that the more appropriate test is chosen in a data-driven way, rather than trying them all and then comparing. So, basically, irrespective of using RUVSeq or similar approaches for batch effect correction (they "just" add some complexity to the design), for edges that you mentioned, one would either:

1. Use the default Wald test and then lfcShrink
2. Use the LRT (without additional shrinkage)

Sounds like generally having the LRT as "default" might also be an interesting alternative. We often use lfcShrink also for "normal" cases if there are enough hits just to be a bit more conservative with the log2fc estimates. Is there an reason not do so so?

[mikelove]

For me, the difference between the two approaches are a focus on effect sizes (where we recommend since 2014 performing effect size shrinkage and using thresholded tests to define regions of biological significance) vs a p-value only approach. And yes, I agree that lfcShrink should be part of the "normal" pipeline (hence it's one of the three commands we put in the Quick Start at the top of the vignette). If you just want p-values and care less about effect sizes, then LRT can be more robust, which has been described in the GLM literature, as it is less susceptible to issues when the estimated coefficient is on the boundary of the parameter space and estimate and SE head toward +/- infinity. We tried to make it trivial to go either direction (effect size vs LRT), and the glmGamPoi route uses LRT exclusively.

I'm less in favor of automated switches in the code than when I first wrote DESeq2 (where we have e.g. the automated outlier treatment). I now stress that you should really be looking at the results by eye, performing QC and looking at plots of counts over sample groups, etc.