Open ishida-md opened 2 months ago
Could be bit rot. Some experimentation showed that even low-quality mappings provided a slightly better copy number signal than removing those reads, so filtering on quality isn't recommended anymore. But MAPQ of 0 is a special case implying unmapped or ambiguously mapped reads. I wouldn't recommend -q 60 (even if it worked) but -q 10 might be appropriate here.
Thank you for your response. I chose MAPQ=60 in the snippet as an extreme example. I have tried pre-filtering with the minimum MAPQ=20 and saw some differences.
unfiltered
filtered
chr1:13,446,216-13,450,648 (hg19) PRAMEF13
chr1:104,291,000-104,299,000 (hg19) AMY1C
Likely fixed in https://github.com/etal/cnvkit/pull/912. Can you try the latest development version and see if it works for you now?
Yes, cnvkit.py coverage -q is now working. Thank you! Could you consider adding -q option to cnvkit.py batch?
Hi, I am running the latest cnvkit image on the docker hub. I get spurious calls where many reads with mapq = 0. I tried cnvkit.py coverage with the -q option, but it does not do anything. Is this a bug?
Here is the snippet: singularity exec -e --env OMP_NUM_THREADS=1 --bind /home cnvkit_0.9.11.sif cnvkit.py coverage -o mapq0.cnn test.bam xgen.t750.bed
singularity exec -e --env OMP_NUM_THREADS=1 --bind /home cnvkit_0.9.11.sif cnvkit.py coverage -o mapq60.cnn -q 60 test.markdup.bam xgen.t750.bed
mapq0.cnn and mapq60.cnn are identical although I see a lot of mapq = 0 reads on IGV.