Closed jennahamlin closed 2 years ago
Is this with read data or assemblies?
(I'd also have a look at your k-mer range and plots to make sure they look ok, it seems like you might want to increase the min-k value.)
Yes, these are reads and when I create the database using assemblies, the issue of ambiguous bases goes away, all samples pass QC filters, and the plot fits look okay.
I still find it odd that so many samples would be pruned if I had used read data.
Thank you
Seems like we probably have some issue counting Ns in reads, I wonder if it might be that we're dividing by expected sequence length rather than total bases in the reads. I'll look into it
Indeed, the denominator in this check is wrong for reads. sketchlib v2.0.1 & poppunk 2.5.0 onwards will save whether a sample was reads to the database, and if so the --prop-n
cutoff will not be used.
For lower versions, the fix is to set --prop-n
to a very large value, or turn the QC off.
Versions: poppunk 2.4.0 pp-sketchlib 2.0.0
Command used:
Output returned:
Output returned:
Describe the bug Unclear to me if the flag --prop-n is dealing with the ambiguous bases request as the qc report states 'Ambiguous sequence too high'. I set --prop-n to 80% but still gives same message when I do include --prop-n and when I don't. Additionally, I don't believe most of my data (n =226 out of 251) has that many ambiguous sequences.