[BioC] DESeq error thrown during estimateDispersions w/ coxReid method

[Simon Anders]

Hi Steve

First, very sorry that your mail stayed unanswered for so long. I had it 
on my to-do list, and the forgot about until Chris asked about the same 
issue on the list yesterday. So, to close this thread, too:

On 2012-04-26 00:41, Steve Lianoglou wrote:
> (maybe this is more appropriate for bioc-devel, but ...)
>
> Using R-2.15-patched, DESeq_1.9.4
>
> DESeq isn't liking 1 row in my count data, and throws an error in the
> `estimateAndFitDispersionsWithCoxReid` function. Specifically this
> error:
>
> Error in glm.fit(mm, y, family = MASS::negative.binomial(initialGuess),  :
>    NA/NaN/Inf in 'x'
>
> The count data looks like this, where w1,w2,w3 are replicates of experiment w:
>
> w1    w2     w3     x1     x2     x3     y1    y2    z1   z2
>   0      0      18       0      52      0       0      0     1     1
>
> Ok -- it's weird, I'll grant you that. Still, instead of killing the
> entire run (it's a little time consuming) I was curious if something
> could be done about such troublesome count rows?
>
> For instance, in the `apply` loop we could wrap glm.fit into a
> tryCatch() and just set the dispersion for this row as NA. When all is
> said and done, perhaps emit a warning about "Can not estimate
> dispersions for XX rows" and set their dispersion to `max(disps)`. You
> could even set as an attribute of the object that is ultimately
> returned the indices of the "bad" rows that the user could then remove
> after wards.
>
> Would that be a reasonable thing to do?

Very, you are right, a "try" should be in there. In fact, I had added a 
"try" fo 'fitNbinomGLMs' for the same reason and had just forgotten to 
to the same in 'estimateDispersions'. Now fixed in in DESeq version 
1.8.3 (release) and 1.9.7 (devel).

> Also, would you accept a patch to the
> `estimateAndFitDispersionsWithCoxReid` that parallelizes it in a
> similar way that DEXseq parallelizes some of its cpu-intensive bits?

Yes, this is something else, I wanted to do since long, and have done in 
some internal test version but never carried over to trunk. SO, if you 
have a patch, might be helpful.

Cheers
   Simon