unmapped vs mapped in covplot

[shoyosato]

I produced a covplot for my data and it shows 51.57% unmapped reads. This number does not match the mapped reads info from my .cov or .json. Are these supposed to be congruent? I was expecting the no-hits blobs to be larger in the blobplot to assess where my organism's coverage/gc content fall. I am wondering if this 51.57% should be part of the no-hits blobs. Thank you!

here is my covplot:

Here are the first four lines from my .cov file:

## 1.1.1
## Total Reads = 22276300
## Mapped Reads = 22265834
## Unmapped Reads = 10466

and some info from the end of the .json:

"reads_total": 22276300, "reads_mapped": 22265834, "reads_unmapped": 0, 

[dtusso2020]

Hello shoyosato

Did you solve your problem? The same happens to me.

[shoyosato]

Hey Diana!

Ya, it seemed to be an issue with long reads for me. I originally mapped the long reads back to the LR assembly to calculate coverage. I reran with short read data and the mapped bar bumped up to 98.6%. Sorry that the fix didn't really solve the root of problem....

[mrmrwinter]

I'm also having this issue, also when using long reads. Is there a way to change the mapping module to minimap2, vulcan, or something similar?

In the meantime I will try fragmenting the long reads and seeing if they map better

[DRL]

Blobtools only parses the BAM file ... see here for a approximate description how it works (actually done via pysam now, but should be the same filters than samtools output)

For those people seeing weird things, check how your mapper made the alignments. Most likely there are multiple alignments or weird SAM flags for a given long read which then inflates numbers weirdly.

[Sabrin2020]

How to do the same plots please with blobtools2?

[magrgic]

Hello,
I have a similar issue when using long reads; did anyone manage to get around it?

[rlopez-seaslugs]

Hi! I am also experiencing a similar issue. Has anyone been able to address this issue using long reads?

[sgirald]

hi, I am experiencing the same issue. BlobTools reported ~55% “unmapped” assembly. However, samtools flagstat and idxstats show all contigs have mapped reads, and base-level coverage confirms nearly 100% of the assembly is supported. It seems the “unmapped” fraction in BlobTools may not reflect actual assembly coverage for long-read data. Could this behavior be clarified or adjusted for long-read assemblies?

[DRL]

hi @sgirald,
since metrics of coverage for (un-paired) long-read data is trivial to figure out, I really don't see the point.

Keep in mind that you can compute coverage for your sequences in whatever way you like and give blobtools the coverage info as .cov files.