Skip to content

unmapped vs mapped in covplot #117

Open
Open
unmapped vs mapped in covplot#117

Description

@shoyosato
shoyosato
opened on Nov 12, 2021

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:

epibro_blob blobDB json bestsum phylum p8 span 100 blobplot read_cov bam0

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,

Activity

  1. dtusso2020 commented on Mar 2, 2022

    @dtusso2020
    dtusso2020
    on Mar 2, 2022

    Hello shoyosato

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

  2. shoyosato commented on Mar 2, 2022

    @shoyosato
    shoyosato
    on Mar 2, 2022
    Author

    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....

  3. mrmrwinter commented on Jun 17, 2022

    @mrmrwinter
    mrmrwinter
    on Jun 17, 2022

    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

  4. DRL commented on Jun 17, 2022

    @DRL
    DRL
    on Jun 17, 2022
    Owner

    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.

  5. Sabrin2020 commented on Oct 14, 2022

    @Sabrin2020
    Sabrin2020
    on Oct 14, 2022

    How to do the same plots please with blobtools2?

  6. magrgic commented on Mar 1, 2024

    @magrgic
    magrgic
    on Mar 1, 2024

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

  7. rlopez-seaslugs commented on Mar 27, 2025

    @rlopez-seaslugs
    rlopez-seaslugs
    on Mar 27, 2025

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

  8. sgirald commented on Oct 29, 2025

    @sgirald
    sgirald
    on Oct 29, 2025

    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?

  9. DRL commented on Oct 29, 2025

    @DRL
    DRL
    on Oct 29, 2025
    Owner

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions