Announcement

Collapse

Welcome to the New Seqanswers!

Welcome to the new Seqanswers! We'd love your feedback, please post any you have to this topic: New Seqanswers Feedback.
See more
See less

Incorrect bbmap quality trimming

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Incorrect bbmap quality trimming

    I am using bbmap to trim bases below a certain quality threshold in a FASTQ file. The file looks fine to me in terms of quality scores, but when I run bbmap it trims almost all the bases away and seems to leave just one base per read, despite most of the bases meeting the quality threshold.

    I am not sure if this makes any difference, but this is a FASTQ file generated by merging overlapping paired-end reads and adjusting quality scores to reflect this with SeqPrep. As a result, most of the quality scores are high (lowercase ASCII characters) and I am setting a trim threshold of 59. Nonetheless, many more of the bases in the file should meet this threshold than what bbmap is outputting.

    In case it is helpful, I pasted my command below. I also pasted a few lines of the FASTQ input.

    Code:
    ./reformat.sh in=./samples/B10C_merge.fq out=./samples/B10C_trim.fq qtrim=rl trimq=59 qin=33 qout=33
    Code:
    @M02713:293:GW200329AmpliconEZC0318:1:2105:15470:1423 1:N:0:TGATCACG+AGGCGAAG
    GATCTGTTGCTGCCCCAGGATGTTGAGGAGTTTTTTGAAGGCCCAAGTGAAGCCCTCCAAGTGTTAGGAGCTCCTGCAGCACAGGCCCTGCCCCAGCTACTCCATGGCCCCCGTCATCTTTTGTCCCTTCTCAAAAAACTTACCAGGGCAACTATGGCTTCCACCTGGGCTTCCTGCAGTC
    +
    hhiijlllllllmmnnnnnnnnooooooomnooonnnmnoooonnoooooonnnooonoooooooooooonlooooooooonnnnmmmnnnnonnnoooooooonnnnnnlmnnnnnoononnonoononnnnnooolnooooooonnnnnoooooooonnnnnnnnnmmmjmmmmijjij
    @M02713:293:GW200329AmpliconEZC0318:1:2105:18370:1751 1:N:0:TGATCACG+AGGCGAAG
    TTTGATGATGGCTGTCATGTCTGGGAGCCTGTGGCTGAAGAAAAAGGAGGAGAGAGATGGCAGAAGCTGCTGGTGGCGGGGCTTCTTCTGCAGGATGGAAATGGCTCTGGACTTGGCGGTGGCTGATGCCCCTCGCTCTGCTGCCGCTTGGTTCTGGACAGCAGCCGGGTAATGGCTGCTGCGGCGGCTGCTGGATGGTTGCAGCGACTGGGCCTGCTTCTCCTCAGCAGCCA
    +
    fggggkkkkkkkllllllkgllmmmmlllmmmgmmmlmmmmmmmmlllmlmmnmmmmnnnmnmmnmnnnmlmnnnmnmmnmnmnoonooomooomoonnmonooojnnolnonnnnlnmbhkojmWWljnnmkmjiUjcmlllnniigllnahWaWmWmmgkhllmmnn`jninnmikehhkagdTj`T`UUa`T`WbWaTThhh`TgfgklekkkeVhVV[gU^UQZPZQfO
    @M02713:293:GW200329AmpliconEZC0318:1:2105:12451:2026 1:N:0:TGATCACG+AGGCGAAG
    TTTGATGATGGCTGTCATGGCAAAGGGAGGAGGACAGGCTTCTCCGTCCCCAGGAAGCAACTGGAGGCCCAGCTGAGCCCAGCTCTGCCTCAGCTTCCCCATCTGTAAAATGGGGTGATGGGCACCAGGCGGTAGGTGCAGCCTCACTGTCTTCTTGCCCCCAGCGGAGCTGATGGAGCGGGCCGCGGTGCCACCCCTTTGGCCGGCCCTGTACCCACCAGGCCGCAGCTCCCTGCACCACGCCCAGCAGCTGCAGCTCTTCTCCTCAGCAGCC
    +
    CABCCFFFFFFFGGGGGGGGGGHHmmlmllllllmmhllmmmmmkammllmmllmmlmmmmmlmmmljlllmmlmmmmllmmmmmmmmmmmmmmmmmlmmmmmmmmmmmmmmmmlllklmnnnmmmnngnmmmkmmnnnknnooooomonoonljnnnnnlmmmnnnnnnnoonlmknnmlmmmmmlmmdhjTllmmmmllUhllgkmlmmmlllmlmllllllllmllllmmmmklllllmlkmklmHGHHGGGGGGGGGGFCFFFFCCCCCB
    @M02713:293:GW200329AmpliconEZC0318:1:2105:19453:2143 1:N:0:TGATCACG+AGGCGAAG
    GAGGGGCATCAGCCACCGCCAAGTCCAGAGCCATTTCCATCCTGCAGAAGAAGCCCCGCCACCAGCAGCTTCTGCCATCTCTCTCCTCCTTTTTCTTCAGCCACAGGCTCCCAGACATGACAGCCATCATCAA
    +
    [Ofd[Q]RS^RRib;eimnlnmnjnmnjYiiimmmYmnjVnmi[iomnomoldnnnmnlmimooooomoonnoojomlkjnlnnnonnlkomkjoonnonomomonnlmonmnjnmnnnnjmljmmmmiiiii
    @M02713:293:GW200329AmpliconEZC0318:1:2105:11660:2539 1:N:0:TGATCACG+AGGCGAAG
    AGCCCCGCCACCAGCAGCTTCTGCCATCTCTCTCCTCCTTTTTCTTCAGCCACAGGCTCCCAGACATGACAGCCATCATCAAA
    +
    Qbiiijkjkijmjmnnnnnmmnnooonnnnonnnoonlooommoonnooooooonnmoonnnnmmnnnnnnmmmmmmmiifgi
    @M02713:293:GW200329AmpliconEZC0318:1:2105:18713:2826 1:N:0:TGATCACG+AGGCGAAG
    CTGTTATTGCTAGCGTTTTAGCACAGGTGCAGCTGGTGGAGTCTGGGGGAGGATTGGTCCAGGCTGGAGGCTCTCTGAGACTCTCCTGTGCAGGCTCTTCACCCGCCTTCACTAAACTCGCCGTGGGGTGGTTCCGCCAGGCTCCAGGAAAGGAGCGTGAGTTTGTCGCAGCTTGTGGTTGGAGTGGAAGTGATACATACTATGCGGACTCCGTGAAGGGCCGATCCAGCATCTTCAGAGACAACGCCAAGAACACGGTGTATCTGCAAATGAACAGCCTGAAACCTGAGGACACGGCCATTTATTACTGTGCAGTGAGAGTATGGTGGGCGGGCGATTGGGATACAGAAACGCAGTATGATTACTGGGGCCAGGGGACCCAGGTCACCGTCTCCTCAGAATTCGGTAAGCCTATCCCTAAC
    +
    BBBBBFFFFFFFFGGEFGGGGGHHHHHGHFHHFHHHGFGGHFHHGHHGGGGGGHHHEFGF[email protected]DGFG<@CGGGHGGGGFGGECEHFHEHHAGGHHGDFGGCGFGFFGHGGGGlkjflgUTUghU_lgkl`^kllkgh^lkigejlgjaejlkjlgilhdcjkilahmlllmmlmkmmmkjllkhkKgmHHGGHFGFFHGHHEGDDGFHHGHHHHHFGHHHHFGEEGFFGHFDBGHGGFFHHFHHHFHHGHFHFFHHEHFGFFHGGGEECEEEAFCF3HFGEGFHGHHECFEHFHFHFGD5HHHDFE1GGHFHHHHFFCHFFG3FFAEEFAGHFGHEDBFEGFEBGGGGGFFFFFFFAA>33
    @M02713:293:GW200329AmpliconEZC0318:1:2105:11972:2903 1:N:0:TGATCACG+AGGCGAAG
    GGGGCTTCTTCTGCAGGATGGAAATGGCTCTGGACTTGGCGGTGGCTGATGCCCCTCGCTCTGCTGCCGCTTG
    +
    jkikkjjmmmmmnnnnnnnnnnoooooooonoooomnnnnnnnnmoononnmnnmmmmmmnmjjjjklkkkjj
    @M02713:293:GW200329AmpliconEZC0318:1:2105:13695:2965 1:N:0:TGATCACG+AGGCGAAG
    TGGCTGCTGAGGAGAAGCAGGCCCAGTCGCTGCAACCATCCAGCAGCCGCCGCAGCAGCCATTACCCGGCTGCTGTCCAGAACCAAGCGGCAGCAGAGCGAGGGGCATCAGCCACCGCCAAGTCCAGAGCCATTTCCATCCTGCAGAAGAAGCCCCGCCACCAGCAGCTTCTGCCATCTCTCTCCTCCTTTTTCTTCAGCCACAGGCTCCCAGACATGACAGCCATCATCAAA
    +
    OZQPQPQTS8_\VV_VT`T`Sh__;TaTVV`TTh<`Ua;aWW`TTTaTS`SV8VTgVimmmka<mkfiUiU_TW`WiWWaaWhUaTTfiVVbbVUjjTgbTmmlWWlWmcWnhcnnnnnnmmkooommmoooonimmYVonmmmnioooollnnnmnmnmnnnmnnnnnmmnnnnnmmnnkmmlmmllmmmmmmoolommmmlmllllmmmllllllllllkkkkkkkhihgg
    @M02713:293:GW200329AmpliconEZC0318:1:2105:15588:3299 1:N:0:TGATCACG+AGGCGAAG
    TGGCTGCTGAGGAGAAGCAGGCCCAGTCGCTGCAACCATCCAGCAGCCGCCGCAGCAGCCATTACCCGGCTGCTGTCCAGAACCAAGCGGCAGCAGAGCGAGGGGCATCAGCCACCGCCAAGTCCAGAGCCATTTCCATCCTGCAGAAGAAGCCCCGCCACCAGTAGCTTCTGCCATCTCTCTCCTCCTTTTTCTTCAGCCACAGGCTCCCAGACATGACAGCCATCATCAAA
    +
    4ZOPP\6TT8^\`9UUU9T_ScaS;TTT`UUUTa<b;U0aTTTT<TbT_`SUUVT`VinmmiaUh`TiUTUiTjaWWajjjWbUbTTSiVnmmljiUTTbTllmWjbWUWVlgcnnlmhnnnnoonmilooooonnonmonommonooonfnnnnmnmnnnnmn`mmnnmmnnnnnmmmmnmmmnmlllmmlmmlmlmmmmmmmlllmmmmllllllllllkkkkkkkhhhhh

  • #2
    trim threshold of 59
    If this data is in Illumina encoding (Phred+64) then you need to specify "qin=64". If you need the Q scores reformatted to sanger then "qout=33".

    Comment


    • #3
      I thought Phred+64 was no longer used for Illumina scores? I am pretty sure mine is encoded in Phred+33. And I specified qin=33 and qout=33 in the command.

      The reason the threshold is 59 is not because it is Phred+64, but because the scores were increased during merging.

      Comment


      • #4
        I see. Did you merge the data using `bbmerge`? If not can you try it instead of whichever program you used? I am not sure having Q-scores that go past even Illumina encoding make sense.

        Comment


        • #5
          Ah I figured out what was happening. Your comment about the high Phred scores got me thinking on the right track. After looking at the documentation further it seems that bbmap has a flag to cap base quality which is set to 41 by default, which would eliminate almost all of my bases, explaining my results.

          I added the following flags

          maxcalledquality=1000 ibq

          to remove the cap on quality score and also 'ibq' to ignore any base scores it might consider problematic in case they are still being flagged somehow. This fixed my issue and outputted a properly trimmed file.

          Comment

          Working...
          X