I run dada2 using docker and encountered the following error:
3787446000 total bases in 15781025 reads from 1 samples will be used for learning the error rates.
Error in dada_uniques(names(derep[[i]]$uniques), unname(derep[[i]]$uniques), :
Lambda out-of-range error.
Calls: learnErrors -> dada -> dada_uniques
Execution halted
Could anyone help with this? Thanks a lot.
Huh, that's coming from deep in the C code on a check that a value is in the valid range of 0-1. In principle you should never see this error...
Is this reproducible, i.e. do you get the same error each time?
Can you provide the exact command you are calling to get this error?
And also R.version and packageVersion("dada2").
Thanks a lot for your reply. This is not reproducible, I run my code successfully before without using docker. The following are the commands I used:
library(dada2)
path<- "/data3/Dada2_results/Data1"
list.files(path)
fnFs <- list.files(path, pattern="Read1.fq.gz", full.names = TRUE)
fnRs <- list.files(path, pattern="Read3.fq.gz", full.names = TRUE)
filtFs <- file.path(path, "filtered", "Raw_Read1_filt.fq.gz")
filtRs <- file.path(path, "filtered", "Raw_Read3_filt.fq.gz")
out <- filterAndTrim(fnFs, filtFs, fnRs, filtRs, truncLen=c(240,160), maxN=0, maxEE=c(2,2), truncQ=11, rm.phix=TRUE, compress=TRUE, multithread=TRUE)
errF <- learnErrors(filtFs, nbases = 1e+08, multithread=TRUE)
errR <- learnErrors(filtRs, nbases = 1e+08, multithread=TRUE)
pdf("errF.pdf")
plotErrors(errF, nominalQ=TRUE)
dev.off
pdf("errR.pdf")
plotErrors(errR, nominalQ=TRUE)
dev.off
derepFs <- derepFastq(filtFs, verbose=TRUE)
derepRs <- derepFastq(filtRs, verbose=TRUE)
dadaFs <- dada(derepFs, err=errF, multithread=TRUE)
dadaRs <- dada(derepRs, err=errR, multithread=TRUE)
mergers <- mergePairs(dadaFs, derepFs, dadaRs, derepRs, verbose=TRUE)
No idea. The exception is happening because a value < 0 or > 1 is being generated by multiplying a bunch of other numbers which themselves should all be between 0 and 1. We've never had this error message reported for that I remember. Could it be some architecture specific floating point overflow/underflow bug? But why then only via docker?
I'm not sure, I'd suggest a workaround for now. Could you also provide the details of the dockerized version of dada2 you are using though as well? And is that version publicly available?
Any updates on this?
Closing in the absence of any further reports of this error.
Hey @benjjneb, looks like this might be a similar or related error here:
https://forum.qiime2.org/t/dada2-error-return-code-1-bad-lambda/12527
Specifically it looks like the user is hitting an execution point that indicates they have a lambda < 0 or > 1.
Ugh. Thanks for the heads up. This error should never be seen, and is basically there to guard against a floating point arithmetic issue. We have never been able to replicate this error since this issue was reported.
It looks like Nick is asking the right kinds of questions on the Q2 thread (https://forum.qiime2.org/t/dada2-error-return-code-1-bad-lambda/12527/8). The key here would be finding a way to replicate the error, which at this point seems to have some level of system specificity.
@benjjneb, this error _seems_ to have raised its ugly head again.
As a side note, it looks like you _may_ have the ingredients for a reproducible example in the forum post mentioned previously. The user shared a link to their (public) data, and gives a pretty solid description of the EC2 instance they were running on. Not sure whether a similar EC2 config would still be convenient to set up, but at least it's not an institutional cluster. :shrug:
OK thanks for noting this. I will re-open the issue.