<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:lang="en">
  <teiHeader>
    <fileDesc>
      <titleStmt>
        <title>Trimmomatic: a flexible trimmer for Illumina sequence data</title>
        <author>Anthony M. Bolger</author>
        <author>Marc Lohse</author>
        <author>Bjoern Usadel</author>
      </titleStmt>
      <publicationStmt>
        <p>Tag layer of the DHSS Meta-Tagging Project. The article text is reproduced from the
           staged copy named in sourceDesc and is not altered; the tags are held separately in
           standOff so that overlapping and nested spans are preserved.</p>
      </publicationStmt>
      <sourceDesc>
        <bibl>
          <title>Trimmomatic: a flexible trimmer for Illumina sequence data</title>
          <date>2014</date>
          <publisher>Bioinformatics</publisher>
          <idno type="DOI">10.1093/bioinformatics/btu170</idno>
          
          <idno type="record">bolger2014-trimmomatic-flexible-trimmer</idno>
          <note type="staged-file">bolger2014-trimmomatic-flexible-trimmer.txt, the project's staged copy</note>
          <note type="text-sha1">3f34c7117d93fb9c6765268452e4594e41f3b8e0</note>
          <note type="rights">cc-by</note>
        </bibl>
      </sourceDesc>
    </fileDesc>
    <profileDesc>
      <textClass><keywords><term>bioinformatics</term></keywords></textClass>
      <particDesc>
        <person xml:id="paper"><p>the paper's own words</p></person>
        <person xml:id="tagger"><p>the tag layer; a sentence written by the tagger about the
          paper, always anchored to a quotation but not itself a quotation</p></person>
      </particDesc>
    </profileDesc>
    <revisionDesc>
      <change when="2026-10-06"
              who="build_paper_edition.py">185 spans located by searching the stored text for the quote's exact words, allowing any whitespace between them</change>
    </revisionDesc>
  </teiHeader>
  <standOff>
    <spanGrp type="tags">
      <span xml:id="t0" from="#a15" to="#a16" type="object_of_study" ana="#object_of_study" resp="#paper">Trimmomatic&#x27;s paired-end-aware trimming algorithms, adaptive quality filtering, architecture, and effects on alignment and assembly</span>
      <span xml:id="t1" from="#a13" to="#a14" type="research_question" ana="#research_question" resp="#paper">how to preprocess Illumina reads flexibly and efficiently while preserving pairing and improving downstream reference-based and de novo analyses</span>
      <span xml:id="t2" from="#a1" to="#a2" type="contribution" ana="#contribution" resp="#paper">Trimmomatic, a pair-aware pipeline with simple and palindrome adapter detection plus sliding-window and Maximum Information quality filtering</span>
      <span xml:id="t3" from="#a1" to="#a2" type="claim_type" ana="#claim_type" resp="#paper">method</span>
      <span xml:id="t4" from="#a5" to="#a6" type="phenomenon" ana="#phenomenon" resp="#paper">technical-sequence contamination and position-dependent quality loss in Illumina sequence reads</span>
      <span xml:id="t5" from="#a61" to="#a62" type="method" ana="#method" resp="#paper">system-or-tool-building<term>system-or-tool-building</term></span>
      <span xml:id="t6" from="#a23" to="#a24" type="mechanisms" ana="#mechanisms[0]" resp="#tagger" cert="0.95">A mismatched seed locates candidates, local alignment scores them, and the aligned region plus suffix is removed.<term>simple-mode seed and extend</term></span>
      <span xml:id="t7" from="#a25" to="#a26" type="mechanisms" ana="#mechanisms[1]" resp="#tagger" cert="0.95">Equal valid length, reverse-complement sequence, and opposite-adapter contamination are tested together.<term>palindrome signal combination</term></span>
      <span xml:id="t8" from="#a27" to="#a28" type="mechanisms" ana="#mechanisms[2]" resp="#tagger" cert="0.95">Adapters are prepended and the combined paired sequences are globally aligned.<term>paired-read alignment</term></span>
      <span xml:id="t9" from="#a31" to="#a32" type="mechanisms" ana="#mechanisms[3]" resp="#tagger" cert="0.95">Sixteen bases become a 64-bit seed and XOR/popcount measures mismatches.<term>bitwise seed comparison</term></span>
      <span xml:id="t10" from="#a39" to="#a40" type="mechanisms" ana="#mechanisms[4]" resp="#tagger" cert="0.95">A moving mean-quality threshold removes the read suffix after consecutive poor bases.<term>Sliding Window</term></span>
      <span xml:id="t11" from="#a45" to="#a46" type="mechanisms" ana="#mechanisms[5]" resp="#tagger" cert="0.95">Trimming becomes stricter later in a read as extra bases add less value and more error risk.<term>adaptive strictness</term></span>
      <span xml:id="t12" from="#a49" to="#a50" type="mechanisms" ana="#mechanisms[6]" resp="#tagger" cert="0.95">A logistic value curve rewards reads crossing a user-defined useful length.<term>length threshold</term></span>
      <span xml:id="t13" from="#a51" to="#a52" type="mechanisms" ana="#mechanisms[7]" resp="#tagger" cert="0.95">Retained length contributes a linear information score.<term>coverage factor</term></span>
      <span xml:id="t14" from="#a53" to="#a54" type="mechanisms" ana="#mechanisms[8]" resp="#tagger" cert="0.95">Per-base correctness probabilities accumulate into a read error score.<term>error factor</term></span>
      <span xml:id="t15" from="#a59" to="#a60" type="mechanisms" ana="#mechanisms[9]" resp="#tagger" cert="0.95">The peak of the length, coverage, and error score determines the trim point.<term>combined score</term></span>
      <span xml:id="t16" from="#a61" to="#a62" type="mechanisms" ana="#mechanisms[10]" resp="#tagger" cert="0.95">Ordered steps may inspect single reads or pairs while pairing state is tracked.<term>pipeline architecture</term></span>
      <span xml:id="t17" from="#a63" to="#a64" type="mechanisms" ana="#mechanisms[11]" resp="#tagger" cert="0.95">Multiple CPU cores improve preprocessing performance.<term>multithreading</term></span>
      <span xml:id="t18" from="#a17" to="#a18" type="limitations" ana="#limitations[0]" resp="#tagger" cert="0.95">Short partial adapters cannot satisfy simple mode&#x27;s minimum overlap and are not detectable there.</span>
      <span xml:id="t19" from="#a29" to="#a30" type="limitations" ana="#limitations[1]" resp="#tagger" cert="0.95">Palindrome mode works only on paired-end data and only detects adapter read-through.</span>
      <span xml:id="t20" from="#a21" to="#a22" type="limitations" ana="#limitations[2]" resp="#tagger" cert="0.95">Trimmomatic&#x27;s technical-sequence methods do not filter or classify barcode data.</span>
      <span xml:id="t21" from="#a11" to="#a12" type="limitations" ana="#limitations[3]" resp="#tagger" cert="0.95">Sequential single-purpose tools create large intermediate files and require pair awareness in every tool.</span>
      <span xml:id="t22" from="#a9" to="#a10" type="limitations" ana="#limitations[4]" resp="#tagger" cert="0.95">A shell pipeline can lose read-pair relationships and cannot always assess the pair as a unit.</span>
      <span xml:id="t23" from="#a67" to="#a68" type="limitations" ana="#limitations[5]" resp="#tagger" cert="0.95">Logging every read&#x27;s trimming status has significant performance cost.</span>
      <span xml:id="t24" from="#a89" to="#a90" type="limitations" ana="#limitations[6]" resp="#tagger" cert="0.95">Single-end fallback makes alignments suboptimal in the cross-tool comparison.</span>
      <span xml:id="t25" from="#a93" to="#a94" type="limitations" ana="#limitations[7]" resp="#tagger" cert="0.95">The runtime benchmark cached a small dataset and may not represent I/O-limited practice.</span>
      <span xml:id="t26" from="#a97" to="#a98" type="limitations" ana="#limitations[8]" resp="#tagger" cert="0.95">High-quality data with tolerant alignment showed only small preprocessing gains.</span>
      <span xml:id="t27" from="#a103" to="#a104" type="limitations" ana="#limitations[9]" resp="#tagger" cert="0.95">Assemblers that ignore quality scores treat low- and high-quality bases equally.</span>
      <span xml:id="t28" from="#a17" to="#a18" type="controls" ana="#controls[0]" resp="#tagger" cert="0.95">user-defined minimum overlap and alignment threshold<note>eliminates: false-positive simple-mode contaminant matches · outcome: held</note></span>
      <span xml:id="t29" from="#a25" to="#a26" type="controls" ana="#controls[1]" resp="#tagger" cert="0.95">combined read-through symptoms<note>eliminates: weak evidence from any one adapter symptom · outcome: held</note></span>
      <span xml:id="t30" from="#a77" to="#a78" type="controls" ana="#controls[2]" resp="#tagger" cert="0.95">alternative BWA aligner<note>eliminates: result dependence on Bowtie 2 alone · outcome: held</note></span>
      <span xml:id="t31" from="#a91" to="#a92" type="controls" ana="#controls[3]" resp="#tagger" cert="0.95">strict and tolerant alignment settings<note>eliminates: conclusions tied to one mismatch tolerance · outcome: held</note></span>
      <span xml:id="t32" from="#a1" to="#a2" type="concepts" ana="#concepts[0]" resp="#paper" cert="0.95">next-generation sequencing<term>next-generation sequencing</term></span>
      <span xml:id="t33" from="#a1" to="#a2" type="concepts" ana="#concepts[1]" resp="#paper" cert="0.95">NGS<term>NGS</term></span>
      <span xml:id="t34" from="#a1" to="#a2" type="concepts" ana="#concepts[2]" resp="#paper" cert="0.95">read preprocessing tools<term>read preprocessing tools</term></span>
      <span xml:id="t35" from="#a1" to="#a2" type="concepts" ana="#concepts[3]" resp="#paper" cert="0.95">Trimmomatic<term>Trimmomatic</term></span>
      <span xml:id="t36" from="#a1" to="#a2" type="concepts" ana="#concepts[4]" resp="#paper" cert="0.95">paired-end data<term>paired-end data</term></span>
      <span xml:id="t37" from="#a5" to="#a6" type="concepts" ana="#concepts[5]" resp="#paper" cert="0.95">poor quality<term>poor quality</term></span>
      <span xml:id="t38" from="#a5" to="#a6" type="concepts" ana="#concepts[6]" resp="#paper" cert="0.95">technical sequences<term>technical sequences</term></span>
      <span xml:id="t39" from="#a5" to="#a6" type="concepts" ana="#concepts[7]" resp="#paper" cert="0.95">suboptimal downstream analyses<term>suboptimal downstream analyses</term></span>
      <span xml:id="t40" from="#a7" to="#a8" type="concepts" ana="#concepts[8]" resp="#paper" cert="0.95">FASTQ files<term>FASTQ files</term></span>
      <span xml:id="t41" from="#a7" to="#a8" type="concepts" ana="#concepts[9]" resp="#paper" cert="0.95">positional relationship<term>positional relationship</term></span>
      <span xml:id="t42" from="#a9" to="#a10" type="concepts" ana="#concepts[10]" resp="#paper" cert="0.95">pair awareness<term>pair awareness</term></span>
      <span xml:id="t43" from="#a87" to="#a88" type="concepts" ana="#concepts[11]" resp="#paper" cert="0.95">singletons<term>singletons</term></span>
      <span xml:id="t44" from="#a11" to="#a12" type="concepts" ana="#concepts[12]" resp="#paper" cert="0.95">intermediate files<term>intermediate files</term></span>
      <span xml:id="t45" from="#a15" to="#a16" type="concepts" ana="#concepts[13]" resp="#paper" cert="0.95">read trimming and filtering<term>read trimming and filtering</term></span>
      <span xml:id="t46" from="#a3" to="#a4" type="concepts" ana="#concepts[14]" resp="#paper" cert="0.95">read preprocessing<term>read preprocessing</term></span>
      <span xml:id="t47" from="#a17" to="#a18" type="concepts" ana="#concepts[15]" resp="#paper" cert="0.95">simple mode<term>simple mode</term></span>
      <span xml:id="t48" from="#a17" to="#a18" type="concepts" ana="#concepts[16]" resp="#paper" cert="0.95">approximate match<term>approximate match</term></span>
      <span xml:id="t49" from="#a17" to="#a18" type="concepts" ana="#concepts[17]" resp="#paper" cert="0.95">adapters<term>adapters</term></span>
      <span xml:id="t50" from="#a17" to="#a18" type="concepts" ana="#concepts[18]" resp="#paper" cert="0.95">short partial adapter sequences<term>short partial adapter sequences</term></span>
      <span xml:id="t51" from="#a17" to="#a18" type="concepts" ana="#concepts[19]" resp="#paper" cert="0.95">polymerase chain reaction<term>polymerase chain reaction</term></span>
      <span xml:id="t52" from="#a17" to="#a18" type="concepts" ana="#concepts[20]" resp="#paper" cert="0.95">PCR<term>PCR</term></span>
      <span xml:id="t53" from="#a19" to="#a20" type="concepts" ana="#concepts[21]" resp="#paper" cert="0.95">palindrome mode<term>palindrome mode</term></span>
      <span xml:id="t54" from="#a19" to="#a20" type="concepts" ana="#concepts[22]" resp="#paper" cert="0.95">adapter read-through<term>adapter read-through</term></span>
      <span xml:id="t55" from="#a19" to="#a20" type="concepts" ana="#concepts[23]" resp="#paper" cert="0.95">sensitivity and specificity<term>sensitivity and specificity</term></span>
      <span xml:id="t56" from="#a23" to="#a24" type="concepts" ana="#concepts[24]" resp="#paper" cert="0.95">seed and extend<term>seed and extend</term></span>
      <span xml:id="t57" from="#a33" to="#a34" type="concepts" ana="#concepts[25]" resp="#paper" cert="0.95">local alignment<term>local alignment</term></span>
      <span xml:id="t58" from="#a35" to="#a36" type="concepts" ana="#concepts[26]" resp="#paper" cert="0.95">global alignment<term>global alignment</term></span>
      <span xml:id="t59" from="#a31" to="#a32" type="concepts" ana="#concepts[27]" resp="#paper" cert="0.95">16-base fragment<term>16-base fragment</term></span>
      <span xml:id="t60" from="#a31" to="#a32" type="concepts" ana="#concepts[28]" resp="#paper" cert="0.95">64-bit integer<term>64-bit integer</term></span>
      <span xml:id="t61" from="#a31" to="#a32" type="concepts" ana="#concepts[29]" resp="#paper" cert="0.95">bitwise-XOR<term>bitwise-XOR</term></span>
      <span xml:id="t62" from="#a31" to="#a32" type="concepts" ana="#concepts[30]" resp="#paper" cert="0.95">popcount<term>popcount</term></span>
      <span xml:id="t63" from="#a37" to="#a38" type="concepts" ana="#concepts[31]" resp="#paper" cert="0.95">quality filtering alternatives<term>quality filtering alternatives</term></span>
      <span xml:id="t64" from="#a37" to="#a38" type="concepts" ana="#concepts[32]" resp="#paper" cert="0.95">Illumina quality score<term>Illumina quality score</term></span>
      <span xml:id="t65" from="#a39" to="#a40" type="concepts" ana="#concepts[33]" resp="#paper" cert="0.95">Sliding Window<term>Sliding Window</term></span>
      <span xml:id="t66" from="#a39" to="#a40" type="concepts" ana="#concepts[34]" resp="#paper" cert="0.95">single weak base<term>single weak base</term></span>
      <span xml:id="t67" from="#a47" to="#a48" type="concepts" ana="#concepts[35]" resp="#paper" cert="0.95">Maximum Information<term>Maximum Information</term></span>
      <span xml:id="t68" from="#a47" to="#a48" type="concepts" ana="#concepts[36]" resp="#paper" cert="0.95">adaptive approach<term>adaptive approach</term></span>
      <span xml:id="t69" from="#a49" to="#a50" type="concepts" ana="#concepts[37]" resp="#paper" cert="0.95">length threshold<term>length threshold</term></span>
      <span xml:id="t70" from="#a51" to="#a52" type="concepts" ana="#concepts[38]" resp="#paper" cert="0.95">coverage<term>coverage</term></span>
      <span xml:id="t71" from="#a53" to="#a54" type="concepts" ana="#concepts[39]" resp="#paper" cert="0.95">error rate<term>error rate</term></span>
      <span xml:id="t72" from="#a55" to="#a56" type="concepts" ana="#concepts[40]" resp="#paper" cert="0.95">correctness probabilities<term>correctness probabilities</term></span>
      <span xml:id="t73" from="#a61" to="#a62" type="concepts" ana="#concepts[41]" resp="#paper" cert="0.95">pipeline-based architecture<term>pipeline-based architecture</term></span>
      <span xml:id="t74" from="#a61" to="#a62" type="concepts" ana="#concepts[42]" resp="#paper" cert="0.95">paired<term>paired</term></span>
      <span xml:id="t75" from="#a61" to="#a62" type="concepts" ana="#concepts[43]" resp="#paper" cert="0.95">single<term>single</term></span>
      <span xml:id="t76" from="#a63" to="#a64" type="concepts" ana="#concepts[44]" resp="#paper" cert="0.95">multiple threads<term>multiple threads</term></span>
      <span xml:id="t77" from="#a63" to="#a64" type="concepts" ana="#concepts[45]" resp="#paper" cert="0.95">Performance<term>Performance</term></span>
      <span xml:id="t78" from="#a65" to="#a66" type="concepts" ana="#concepts[46]" resp="#paper" cert="0.95">phred+33<term>phred+33</term></span>
      <span xml:id="t79" from="#a65" to="#a66" type="concepts" ana="#concepts[47]" resp="#paper" cert="0.95">phred+64<term>phred+64</term></span>
      <span xml:id="t80" from="#a69" to="#a70" type="concepts" ana="#concepts[48]" resp="#paper" cert="0.95">reference-based alignment<term>reference-based alignment</term></span>
      <span xml:id="t81" from="#a69" to="#a70" type="concepts" ana="#concepts[49]" resp="#paper" cert="0.95">Bowtie 2<term>Bowtie 2</term></span>
      <span xml:id="t82" from="#a69" to="#a70" type="concepts" ana="#concepts[50]" resp="#paper" cert="0.95">BWA<term>BWA</term></span>
      <span xml:id="t83" from="#a69" to="#a70" type="concepts" ana="#concepts[51]" resp="#paper" cert="0.95">de novo assembly<term>de novo assembly</term></span>
      <span xml:id="t84" from="#a69" to="#a70" type="concepts" ana="#concepts[52]" resp="#paper" cert="0.95">Velvet<term>Velvet</term></span>
      <span xml:id="t85" from="#a73" to="#a74" type="concepts" ana="#concepts[53]" resp="#paper" cert="0.95">uniquely aligned reads<term>uniquely aligned reads</term></span>
      <span xml:id="t86" from="#a73" to="#a74" type="concepts" ana="#concepts[54]" resp="#paper" cert="0.95">Maximum Information approach<term>Maximum Information approach</term></span>
      <span xml:id="t87" from="#a73" to="#a74" type="concepts" ana="#concepts[55]" resp="#paper" cert="0.95">Sliding Window approach<term>Sliding Window approach</term></span>
      <span xml:id="t88" from="#a83" to="#a84" type="concepts" ana="#concepts[56]" resp="#paper" cert="0.95">contig N50 size<term>contig N50 size</term></span>
      <span xml:id="t89" from="#a83" to="#a84" type="concepts" ana="#concepts[57]" resp="#paper" cert="0.95">maximum contig size<term>maximum contig size</term></span>
      <span xml:id="t90" from="#a83" to="#a84" type="concepts" ana="#concepts[58]" resp="#paper" cert="0.95">adapter sequence<term>adapter sequence</term></span>
      <span xml:id="t91" from="#a87" to="#a88" type="concepts" ana="#concepts[59]" resp="#paper" cert="0.95">AdapterRemoval<term>AdapterRemoval</term></span>
      <span xml:id="t92" from="#a87" to="#a88" type="concepts" ana="#concepts[60]" resp="#paper" cert="0.95">Scythe/Sickle<term>Scythe/Sickle</term></span>
      <span xml:id="t93" from="#a87" to="#a88" type="concepts" ana="#concepts[61]" resp="#paper" cert="0.95">EA-Utils<term>EA-Utils</term></span>
      <span xml:id="t94" from="#a87" to="#a88" type="concepts" ana="#concepts[62]" resp="#paper" cert="0.95">Cutadapt<term>Cutadapt</term></span>
      <span xml:id="t95" from="#a93" to="#a94" type="concepts" ana="#concepts[63]" resp="#paper" cert="0.95">execution time<term>execution time</term></span>
      <span xml:id="t96" from="#a105" to="#a106" type="concepts" ana="#concepts[64]" resp="#paper" cert="0.95">other tools<term>other tools</term></span>
      <span xml:id="t97" from="#a107" to="#a108" type="concepts" ana="#concepts[65]" resp="#paper" cert="0.95">strict alignment criteria<term>strict alignment criteria</term></span>
      <span xml:id="t98" from="#a107" to="#a108" type="concepts" ana="#concepts[66]" resp="#paper" cert="0.95">poor-quality input data<term>poor-quality input data</term></span>
      <span xml:id="t99" from="#a73" to="#a74" type="unhoused_relations" ana="#unhoused_relations[0]" resp="#tagger" cert="0.95">Maximum Information approach → Sliding Window approach<note>Maximum Information outperforms Sliding Window in both cases.</note></span>
      <span xml:id="t100" from="#a1" to="#a2" type="unhoused_relations" ana="#unhoused_relations[1]" resp="#tagger" cert="0.95">Trimmomatic → read preprocessing tools<note>Trimmomatic was developed as a flexible and efficient preprocessing tool.</note></span>
      <span xml:id="t101" from="#a7" to="#a8" type="unhoused_relations" ana="#unhoused_relations[2]" resp="#tagger" cert="0.95">pair awareness → positional relationship<note>Pair awareness preserves the positional relationship between paired files.</note></span>
      <span xml:id="t102" from="#a17" to="#a18" type="unhoused_relations" ana="#unhoused_relations[3]" resp="#tagger" cert="0.95">simple mode → approximate match<note>Simple mode works by finding an approximate match to a technical sequence.</note></span>
      <span xml:id="t103" from="#a17" to="#a18" type="unhoused_relations" ana="#unhoused_relations[4]" resp="#tagger" cert="0.95">simple mode → short partial adapter sequences<note>Simple mode cannot detect very short partial adapter sequences.</note></span>
      <span xml:id="t104" from="#a19" to="#a20" type="unhoused_relations" ana="#unhoused_relations[5]" resp="#tagger" cert="0.95">palindrome mode → sensitivity and specificity<note>Palindrome mode has greater sensitivity and specificity than simple mode for read-through.</note></span>
      <span xml:id="t105" from="#a33" to="#a34" type="unhoused_relations" ana="#unhoused_relations[6]" resp="#tagger" cert="0.95">simple mode → local alignment<note>Simple mode uses local alignment.</note></span>
      <span xml:id="t106" from="#a35" to="#a36" type="unhoused_relations" ana="#unhoused_relations[7]" resp="#tagger" cert="0.95">palindrome mode → global alignment<note>Palindrome mode uses global alignment.</note></span>
      <span xml:id="t107" from="#a29" to="#a30" type="unhoused_relations" ana="#unhoused_relations[8]" resp="#tagger" cert="0.95">palindrome mode → adapter read-through<note>Palindrome mode is limited to detecting adapter read-through.</note></span>
      <span xml:id="t108" from="#a39" to="#a40" type="unhoused_relations" ana="#unhoused_relations[9]" resp="#tagger" cert="0.95">Sliding Window → single weak base<note>Sliding-window averaging prevents one weak base from discarding later high-quality data.</note></span>
      <span xml:id="t109" from="#a47" to="#a48" type="unhoused_relations" ana="#unhoused_relations[10]" resp="#tagger" cert="0.95">Maximum Information → adaptive approach<note>Maximum Information implements the adaptive quality-filtering approach.</note></span>
      <span xml:id="t110" from="#a61" to="#a62" type="unhoused_relations" ana="#unhoused_relations[11]" resp="#tagger" cert="0.95">pipeline-based architecture → paired<note>The pipeline tracks paired reads separately from single reads.</note></span>
      <span xml:id="t111" from="#a63" to="#a64" type="unhoused_relations" ana="#unhoused_relations[12]" resp="#tagger" cert="0.95">multiple threads → Performance<note>Multiple threads improve performance when CPU cores are available.</note></span>
      <span xml:id="t112" from="#a101" to="#a102" type="unhoused_relations" ana="#unhoused_relations[13]" resp="#tagger" cert="0.95">read preprocessing → adapter sequence<note>Preprocessing prevents adapter sequence incorporation into de novo assemblies.</note></span>
      <span xml:id="t113" from="#a87" to="#a88" type="unhoused_relations" ana="#unhoused_relations[14]" resp="#tagger" cert="0.95">EA-Utils → singletons<note>EA-Utils maintains pairing but loses singleton reads.</note></span>
      <span xml:id="t114" from="#a107" to="#a108" type="unhoused_relations" ana="#unhoused_relations[15]" resp="#tagger" cert="0.95">strict alignment criteria → other tools<note>Strict criteria and poor-quality data make performance differences among tools clearer.</note></span>
      <span xml:id="t115" from="#a13" to="#a14" type="senses" ana="#senses[0]" resp="#tagger" cert="0.95">Trimmomatic as flexible, pair-aware Illumina preprocessing</span>
      <span xml:id="t116" from="#a17" to="#a18" type="senses" ana="#senses[1]" resp="#tagger" cert="0.95">simple mode as generic technical-sequence matching with short-overlap limits</span>
      <span xml:id="t117" from="#a25" to="#a26" type="senses" ana="#senses[2]" resp="#tagger" cert="0.95">palindrome mode as joint paired-read adapter-read-through detection</span>
      <span xml:id="t118" from="#a31" to="#a32" type="senses" ana="#senses[3]" resp="#tagger" cert="0.95">seed as a 64-bit encoding of sixteen bases for fast mismatch counting</span>
      <span xml:id="t119" from="#a39" to="#a40" type="senses" ana="#senses[4]" resp="#tagger" cert="0.95">Sliding Window as fixed local mean-quality suffix trimming</span>
      <span xml:id="t120" from="#a47" to="#a48" type="senses" ana="#senses[5]" resp="#tagger" cert="0.95">Maximum Information as adaptive balance among read uniqueness, coverage, and error</span>
      <span xml:id="t121" from="#a61" to="#a62" type="senses" ana="#senses[6]" resp="#tagger" cert="0.95">pipeline architecture as user-ordered pair-aware processing steps</span>
      <span xml:id="t122" from="#a97" to="#a98" type="senses" ana="#senses[7]" resp="#tagger" cert="0.95">preprocessing value as conditional on input quality and downstream task stringency</span>
      <span xml:id="t123" from="#a99" to="#a100" type="senses" ana="#senses[8]" resp="#tagger" cert="0.95">reference-based benefit as improved alignment rates after contaminant and quality trimming</span>
      <span xml:id="t124" from="#a101" to="#a102" type="senses" ana="#senses[9]" resp="#tagger" cert="0.95">de novo benefit as preventing adapter incorporation and improving assembly continuity</span>
      <span xml:id="t125" from="#a23" to="#a24" type="claim_relations" ana="#claim_relations[0]" resp="#tagger" cert="0.95">builds-on → seed and extend alignment<note>note: Simple mode uses standard seed-and-extend alignment.</note></span>
      <span xml:id="t126" from="#a19" to="#a20" type="claim_relations" ana="#claim_relations[1]" resp="#tagger" cert="0.95">extends → adapter trimming<note>note: Palindrome mode adds pair-aware short read-through detection.</note></span>
      <span xml:id="t127" from="#a69" to="#a70" type="claim_relations" ana="#claim_relations[2]" resp="#tagger" cert="0.95">complements → reference aligners<note>note: Preprocessing is evaluated before Bowtie 2 and BWA.</note></span>
      <span xml:id="t128" from="#a69" to="#a70" type="claim_relations" ana="#claim_relations[3]" resp="#tagger" cert="0.95">complements → de novo assembly<note>note: Preprocessing improves Velvet assembly inputs.</note></span>
      <span xml:id="t129" from="#a1" to="#a2" type="concept_edges" ana="#concept_edges[0]" resp="#tagger" cert="0.95">next-generation sequencing —same-as→ NGS<note>the relation itself is separately evidenced · strength of the relation: 1 · note: Parenthetical abbreviation equivalence. · the relation stated: Next-generation sequencing is abbreviated NGS.</note><term>next-generation sequencing</term><term>NGS</term></span>
      <span xml:id="t130" from="#a17" to="#a18" type="concept_edges" ana="#concept_edges[1]" resp="#tagger" cert="0.95">polymerase chain reaction —same-as→ PCR<note>the relation itself is separately evidenced · strength of the relation: 1 · note: Parenthetical abbreviation equivalence. · the relation stated: Polymerase chain reaction is abbreviated PCR.</note><term>polymerase chain reaction</term><term>PCR</term></span>
      <span xml:id="t131" from="#a5" to="#a6" type="concept_edges" ana="#concept_edges[2]" resp="#tagger" cert="0.95">poor quality —causes→ suboptimal downstream analyses<note>direction on the measure: increases · the relation itself is separately evidenced · strength of the relation: 0.7 · note: Modal &#x27;can&#x27; makes the causal strength partial. · the relation stated: Poor-quality sequence can result in suboptimal downstream analysis.</note><term>poor quality</term><term>suboptimal downstream analyses</term></span>
      <span xml:id="t132" from="#a5" to="#a6" type="concept_edges" ana="#concept_edges[3]" resp="#tagger" cert="0.95">technical sequences —causes→ suboptimal downstream analyses<note>direction on the measure: increases · the relation itself is separately evidenced · strength of the relation: 0.7 · note: Modal &#x27;can&#x27; makes the causal strength partial. · the relation stated: Technical sequences can result in suboptimal downstream analysis.</note><term>technical sequences</term><term>suboptimal downstream analyses</term></span>
      <span xml:id="t133" from="#a73" to="#a74" type="concept_edges" ana="#concept_edges[4]" resp="#tagger" cert="0.95">read preprocessing —causes→ uniquely aligned reads<note>direction on the measure: increases · the relation itself is separately evidenced · strength of the relation: 0.95 · note: Explicit measured increase. · the relation stated: Preprocessing increased the number of uniquely aligned reads.
Audit 2026-09-28: DOUBTFUL - read against its full span and kept, but the span writes &#x27;preprocessing&#x27;, not &#x27;read preprocessing&#x27;.</note><term>read preprocessing</term><term>uniquely aligned reads</term></span>
      <span xml:id="t134" from="#a83" to="#a84" type="concept_edges" ana="#concept_edges[5]" resp="#tagger" cert="0.95">read preprocessing —causes→ contig N50 size<note>direction on the measure: increases · the relation itself is separately evidenced · strength of the relation: 1 · note: Direct measured increase. · the relation stated: Preprocessing increased contig N50 size by 58 percent.
Audit 2026-09-28: DOUBTFUL - read against its full span and kept, but the span writes &#x27;preprocessing&#x27;, not &#x27;read preprocessing&#x27;.</note><term>read preprocessing</term><term>contig N50 size</term></span>
      <span xml:id="t135" from="#a83" to="#a84" type="concept_edges" ana="#concept_edges[6]" resp="#tagger" cert="0.95">read preprocessing —causes→ maximum contig size<note>direction on the measure: increases · the relation itself is separately evidenced · strength of the relation: 0.95 · note: Approximate measured increase. · the relation stated: Preprocessing improved maximum contig size by about 28 percent.</note><term>read preprocessing</term><term>maximum contig size</term></span>
      <span xml:id="t136" from="#a105" to="#a106" type="concept_edges" ana="#concept_edges[7]" resp="#tagger" cert="0.95">Trimmomatic —contrasted-with→ other tools<note>the relation itself is separately evidenced · strength of the relation: 0.95 · note: Direct comparison statement. · the relation stated: Trimmomatic compared favorably against all other tested tools.</note><term>Trimmomatic</term><term>other tools</term></span>
      <span xml:id="t137" from="#a1" to="#a2" type="content_tags" ana="#content_tags.findings[0]" resp="#tagger" cert="0.95">No existing tool combination met the authors&#x27; flexibility, paired-end, and performance requirements.</span>
      <span xml:id="t138" from="#a3" to="#a4" type="content_tags" ana="#content_tags.findings[1]" resp="#tagger" cert="0.95">Trimmomatic was at least competitive and often superior in every tested scenario.</span>
      <span xml:id="t139" from="#a17" to="#a18" type="content_tags" ana="#content_tags.findings[2]" resp="#tagger" cert="0.95">Simple mode detects arbitrary technical sequences but misses short partial adapters.</span>
      <span xml:id="t140" from="#a19" to="#a20" type="content_tags" ana="#content_tags.findings[3]" resp="#tagger" cert="0.95">Palindrome mode improves sensitivity and specificity for adapter read-through.</span>
      <span xml:id="t141" from="#a29" to="#a30" type="content_tags" ana="#content_tags.findings[4]" resp="#tagger" cert="0.95">Combining both modes is required for comprehensive adapter detection.</span>
      <span xml:id="t142" from="#a39" to="#a40" type="content_tags" ana="#content_tags.findings[5]" resp="#tagger" cert="0.95">Sliding-window filtering avoids letting one weak base discard later high-quality sequence.</span>
      <span xml:id="t143" from="#a43" to="#a44" type="content_tags" ana="#content_tags.findings[6]" resp="#tagger" cert="0.95">Maximum Information balances useful read length against accumulated error risk.</span>
      <span xml:id="t144" from="#a73" to="#a74" type="content_tags" ana="#content_tags.findings[7]" resp="#tagger" cert="0.95">Preprocessing increased uniquely aligned reads, especially under strict alignment.</span>
      <span xml:id="t145" from="#a81" to="#a82" type="content_tags" ana="#content_tags.findings[8]" resp="#tagger" cert="0.95">After trimming, almost 78% of low-quality dataset reads aligned perfectly.</span>
      <span xml:id="t146" from="#a83" to="#a84" type="content_tags" ana="#content_tags.findings[9]" resp="#tagger" cert="0.95">Preprocessing increased first-dataset contig N50 by 58% and maximum contig length by about 28%.</span>
      <span xml:id="t147" from="#a85" to="#a86" type="content_tags" ana="#content_tags.findings[10]" resp="#tagger" cert="0.95">Second-dataset N50 improved about 77% and maximum contig length about 55%.</span>
      <span xml:id="t148" from="#a73" to="#a74" type="content_tags" ana="#content_tags.findings[11]" resp="#tagger" cert="0.95">Maximum Information outperformed Sliding Window in both alignment cases.</span>
      <span xml:id="t149" from="#a95" to="#a96" type="content_tags" ana="#content_tags.findings[12]" resp="#tagger" cert="0.95">Trimmomatic remained the best performer on the second dataset, especially in Maximum Information mode.</span>
      <span xml:id="t150" from="#a97" to="#a98" type="content_tags" ana="#content_tags.findings[13]" resp="#tagger" cert="0.95">Preprocessing benefits were modest for high-quality mismatch-tolerant reference alignment but large for low-quality reads and de novo assembly.</span>
      <span xml:id="t151" from="#a107" to="#a108" type="content_tags" ana="#content_tags.findings[14]" resp="#tagger" cert="0.95">Strict criteria and poor input quality made differences between tools clearer.</span>
      <span xml:id="t152" from="#a17" to="#a18" type="content_tags" ana="#content_tags.definitions[0]" resp="#tagger" cert="0.95">approximate local matching of reads against user-supplied technical sequences<term>simple mode</term></span>
      <span xml:id="t153" from="#a25" to="#a26" type="content_tags" ana="#content_tags.definitions[1]" resp="#tagger" cert="0.95">paired-end adapter-read-through detection using reverse-complement and adapter signals<term>palindrome mode</term></span>
      <span xml:id="t154" from="#a19" to="#a20" type="content_tags" ana="#content_tags.definitions[2]" resp="#tagger" cert="0.95">a fragment shorter than the read that leaves opposite-adapter sequence at read ends<term>adapter read-through</term></span>
      <span xml:id="t155" from="#a23" to="#a24" type="content_tags" ana="#content_tags.definitions[3]" resp="#tagger" cert="0.95">initial approximate seed matching followed by local or global alignment<term>seed and extend</term></span>
      <span xml:id="t156" from="#a39" to="#a40" type="content_tags" ana="#content_tags.definitions[4]" resp="#tagger" cert="0.95">5-prime scanning that trims when mean window quality drops below threshold<term>Sliding Window</term></span>
      <span xml:id="t157" from="#a47" to="#a48" type="content_tags" ana="#content_tags.definitions[5]" resp="#tagger" cert="0.95">adaptive choice of trim position from length threshold, coverage, and error factors<term>Maximum Information</term></span>
      <span xml:id="t158" from="#a49" to="#a50" type="content_tags" ana="#content_tags.definitions[6]" resp="#tagger" cert="0.95">minimum useful read length with a steep value transition around a target<term>length threshold</term></span>
      <span xml:id="t159" from="#a51" to="#a52" type="content_tags" ana="#content_tags.definitions[7]" resp="#tagger" cert="0.95">linear information score based on retained sequence length<term>coverage</term></span>
      <span xml:id="t160" from="#a53" to="#a54" type="content_tags" ana="#content_tags.definitions[8]" resp="#tagger" cert="0.95">accumulated likelihood of errors derived from base-quality probabilities<term>error rate</term></span>
      <span xml:id="t161" from="#a61" to="#a62" type="content_tags" ana="#content_tags.definitions[9]" resp="#tagger" cert="0.95">ordered user-configurable steps operating on single reads or complete pairs<term>pipeline-based architecture</term></span>
      <span xml:id="t162" from="#a7" to="#a8" type="content_tags" ana="#content_tags.definitions[10]" resp="#tagger" cert="0.95">forward and reverse reads retaining their shared-fragment positional relationship<term>paired-end reads</term></span>
      <span xml:id="t163" from="#a31" to="#a32" type="content_tags" ana="#content_tags.quantities[0]" resp="#tagger" cert="0.95">16-base — fragment length used for initial seed comparisons</span>
      <span xml:id="t164" from="#a31" to="#a32" type="content_tags" ana="#content_tags.quantities[1]" resp="#tagger" cert="0.95">64-bit — integer width of encoded seeds</span>
      <span xml:id="t165" from="#a57" to="#a58" type="content_tags" ana="#content_tags.quantities[2]" resp="#tagger" cert="0.95">0 to 1 — range of Maximum Information strictness</span>
      <span xml:id="t166" from="#a71" to="#a72" type="content_tags" ana="#content_tags.quantities[3]" resp="#tagger" cert="0.95">2 × 100 bp — read geometry of dataset 1</span>
      <span xml:id="t167" from="#a79" to="#a80" type="content_tags" ana="#content_tags.quantities[4]" resp="#tagger" cert="0.95">2 × 250 bp — read geometry of dataset 2</span>
      <span xml:id="t168" from="#a81" to="#a82" type="content_tags" ana="#content_tags.quantities[5]" resp="#tagger" cert="0.95">&lt;1.5% — raw reads aligned in perfect-match strict mode</span>
      <span xml:id="t169" from="#a81" to="#a82" type="content_tags" ana="#content_tags.quantities[6]" resp="#tagger" cert="0.95">almost 78% — trimmed reads aligned perfectly</span>
      <span xml:id="t170" from="#a83" to="#a84" type="content_tags" ana="#content_tags.quantities[7]" resp="#tagger" cert="0.95">58% — first-dataset N50 gain</span>
      <span xml:id="t171" from="#a85" to="#a86" type="content_tags" ana="#content_tags.quantities[8]" resp="#tagger" cert="0.95">∼77% — second-dataset N50 gain</span>
      <span xml:id="t172" from="#a91" to="#a92" type="content_tags" ana="#content_tags.quantities[9]" resp="#tagger" cert="0.95">&lt;20 000 reads — separation among top three tools under tolerant alignment</span>
      <span xml:id="t173" from="#a23" to="#a24" type="content_tags" ana="#content_tags.variables[0]" resp="#tagger" cert="0.95">alignment score<term>alignment score</term></span>
      <span xml:id="t174" from="#a43" to="#a44" type="content_tags" ana="#content_tags.variables[1]" resp="#tagger" cert="0.95">read quality<term>read quality</term></span>
      <span xml:id="t175" from="#a41" to="#a42" type="content_tags" ana="#content_tags.variables[2]" resp="#tagger" cert="0.95">read length<term>read length</term></span>
      <span xml:id="t176" from="#a49" to="#a50" type="content_tags" ana="#content_tags.variables[3]" resp="#tagger" cert="0.95">length threshold<term>length threshold</term></span>
      <span xml:id="t177" from="#a51" to="#a52" type="content_tags" ana="#content_tags.variables[4]" resp="#tagger" cert="0.95">coverage<term>coverage</term></span>
      <span xml:id="t178" from="#a53" to="#a54" type="content_tags" ana="#content_tags.variables[5]" resp="#tagger" cert="0.95">error rate<term>error rate</term></span>
      <span xml:id="t179" from="#a57" to="#a58" type="content_tags" ana="#content_tags.variables[6]" resp="#tagger" cert="0.95">strictness setting<term>strictness setting</term></span>
      <span xml:id="t180" from="#a75" to="#a76" type="content_tags" ana="#content_tags.variables[7]" resp="#tagger" cert="0.95">quality stringency settings<term>quality stringency settings</term></span>
      <span xml:id="t181" from="#a73" to="#a74" type="content_tags" ana="#content_tags.variables[8]" resp="#tagger" cert="0.95">uniquely aligned reads<term>uniquely aligned reads</term></span>
      <span xml:id="t182" from="#a83" to="#a84" type="content_tags" ana="#content_tags.variables[9]" resp="#tagger" cert="0.95">contig N50 size<term>contig N50 size</term></span>
      <span xml:id="t183" from="#a83" to="#a84" type="content_tags" ana="#content_tags.variables[10]" resp="#tagger" cert="0.95">maximum contig size<term>maximum contig size</term></span>
      <span xml:id="t184" from="#a93" to="#a94" type="content_tags" ana="#content_tags.variables[11]" resp="#tagger" cert="0.95">execution time<term>execution time</term></span>
    </spanGrp>
  </standOff>
  <text>
    <body>
        <p><anchor xml:id="a0"/> Trimmomatic: a flexible trimmer for Illumina sequence data</p>
        <p>Abstract</p>
        <p><anchor xml:id="a1"/>Motivation: Although many next-generation sequencing (NGS) read preprocessing tools already existed, we could not find any tool or combination of tools that met our requirements in terms of flexibility, correct handling of paired-end data and high performance. We have developed Trimmomatic as a more flexible and efficient preprocessing tool, which could correctly handle paired-end data.<anchor xml:id="a2"/></p>
        <p>Results: <anchor xml:id="a3"/>The value of NGS read preprocessing is demonstrated for both reference-based and reference-free tasks. Trimmomatic is shown to produce output that is at least competitive with, and in many cases superior to, that produced by other tools, in all scenarios tested.<anchor xml:id="a4"/></p>
        <p>Availability and implementation: Trimmomatic is licensed under GPL V3. It is cross-platform (Java 1.5+ required) and available at http://www.usadellab.org/cms/index.php?page=trimmomatic</p>
        <p>Contact: usadel@bio1.rwth-aachen.de</p>
        <p>Supplementary information: Supplementary data are available at Bioinformatics online.</p>
        <p>1 INTRODUCTION</p>
        <p><anchor xml:id="a5"/>The presence of poor quality or technical sequences such as adapters in next-generation sequencing (NGS) data can easily result in suboptimal downstream analyses.<anchor xml:id="a6"/></p>
        <p>Nonetheless, it is not trivial to precisely identify such sequences, including partial adapter sequences, while leaving valid sequence data intact ( Li et al. , 2013 ). Furthermore, given the rate with which NGS sequence data are currently being produced ( Mardis, 2008 ), the additional burden of sequence preprocessing must be kept relatively modest so as to avoid adding undue overhead to the bioinformatics pipeline.</p>
        <p><anchor xml:id="a7"/>The preprocessing approach must also not interfere with the downstream analysis of the data. For example, NGS data often come in the form of paired-end reads, and typically, the forward and reverse reads are stored in two separate FASTQ files, which contain reads from each DNA fragment in the same order. Many downstream tools use this positional relationship between pairs, so it must be maintained when preprocessing the sequence data.<anchor xml:id="a8"/></p>
        <p><anchor xml:id="a9"/>The wide range of available NGS library preparations combined with the range of downstream applications demand a flexible approach. It should be possible to choose a set of processing steps to be applied in a user-defined order, and ideally even allow some steps to be included more than once. In other domains, this can be achieved using a shell pipeline to combine multiple tools as required, e.g. in Newick ( Junier and Zdobnov, 2010 ). However, the need for ‘pair awareness’ makes this approach difficult to apply, as the connection between the corresponding reads in the paired files will typically be lost. Correcting this would require an additional step to reconcile the read pairs and store the ‘singleton’ reads separately. Furthermore, the processing steps would not be able to assess the read pair as a unit, which is necessary or at least advantageous in some cases.<anchor xml:id="a10"/></p>
        <p><anchor xml:id="a11"/>The alternative approach of executing a series of tools in succession would involve the creation of intermediate files at each step, a non-trivial overhead given the data size involved, and would still require pair-awareness to be built into every tool used. These issues suggest that the typical approaches to achieve flexibility by combining multiple single-purpose tools are not optimal.<anchor xml:id="a12"/></p>
        <p><anchor xml:id="a13"/>Thus, although many NGS read preprocessing tools exist, none of them, alone or in combination, could offer the desired flexibility and performance, and most were not designed to work on paired-end data. As a result, we developed Trimmomatic as a more flexible, pair-aware and efficient preprocessing tool, optimized for Illumina NGS data.<anchor xml:id="a14"/></p>
        <p>2 ALGORITHMS</p>
        <p><anchor xml:id="a15"/>Trimmomatic includes a variety of processing steps for read trimming and filtering, but the main algorithmic innovations are related to identification of adapter sequences and quality filtering, and are described in detail below. A list of the other processing steps is presented in the Supplementary Materials .<anchor xml:id="a16"/></p>
        <p>2.1 Removal of technical sequences</p>
        <p><anchor xml:id="a17"/>Trimmomatic uses two approaches to detect technical sequences within the reads. The first, referred to as ‘simple mode’, works by finding an approximate match between the read and the user-supplied technical sequence. This mode has the advantage of working for all technical sequences, including adapters and polymerase chain reaction (PCR) primers, or fragments thereof. Such sequences can be detected in any location or orientation within the reads but requires a substantial minimum overlap between the read and technical sequence to prevent false-positive findings. However, short partial adapter sequences, which often occur at the ends of reads, are inherently unable to meet this minimum overlap requirement and therefore are not detectable.<anchor xml:id="a18"/></p>
        <p><anchor xml:id="a19"/>The second mode, referred to as ‘palindrome mode’, is specifically aimed at detecting this common ‘adapter read-through’ scenario, whereby the sequenced DNA fragment is shorter than the read length, and results in adapter contamination on the end of the reads. This is especially the case for longer read length as supported by the Miseq. Although such short fragments should normally be removed during library preparation, in practice this process is not perfectly efficient, and thus many libraries suffer from this problem to some extent. ‘Palindrome mode’ can only be used with paired-end data, but has considerable advantages in sensitivity and specificity over ‘simple’ mode.<anchor xml:id="a20"/></p>
        <p><anchor xml:id="a21"/>Note that the current technical sequence identification approaches in Trimmomatic are not designed to filter or categorize data on the basis of ‘barcodes’.<anchor xml:id="a22"/></p>
        <p>2.1.1 Simple mode</p>
        <p><anchor xml:id="a23"/>In simple mode, each read is scanned from the 5′ end to the 3′ end to determine if any of the user-provided adapters are present. The standard ‘seed and extend’ approach ( Li and Homer, 2010 ) is used to find initial matches between the technical sequences and the reads. The seed is not required to match perfectly, and a user-defined number of mismatches are tolerated. Based on this seed match, a local alignment is performed. If the alignment score exceeds the user-defined threshold, the aligned region plus the remainder after the alignment are removed.<anchor xml:id="a24"/></p>
        <p>Figure 1 illustrates the alignments tested for each technical sequence. The process begins with a partial overlap of the 3′ end of the technical sequence with the 5′ end of the read, as shown in (A). Testing proceeds by moving the putative contaminant toward the 3′ end of the read. In both the partial overlap (A) and complete overlap at the 5′ end (B) scenarios, the entire read will be clipped. If the contaminant is found within the read (C), the bases from the 5′ end of the read to the beginning of the alignment are retained. The testing process continues until only a partial alignment on the 3′ end of the read remains (D).</p>
        <p>Putative sequence alignments as tested in simple mode. The alignment process begins with a partial overlap at the 5′ end of the read ( A ), increasing to a full-length 5′ overlap ( B ), followed by full overlaps at all positions ( C ) and finishes with a partial overlap at the 3′ end of the read ( D ). Note that the upstream ‘adapter’ sequence is for illustration only and is not part of the read or the aligned region</p>
        <p>Simple mode has the advantage that it can detect any technical sequence at any location in the read, provided that the alignment is sufficiently long and the read is sufficiently accurate. However, when only a short partial match is possible, such as in scenarios (A) and (D), the contaminant may not be reliably detectable.</p>
        <p>2.1.2 Palindrome mode</p>
        <p><anchor xml:id="a25"/>As noted above, ‘palindrome mode’ is specifically optimized for the detection of ‘adapter read-through’. When ‘read-through’ occurs, both reads in a pair will consist of an equal number of valid bases, followed by contaminating sequence from the ‘opposite’ adapters. Furthermore, the valid sequence within the two reads will be reverse complements. By detecting all three of these symptoms at once, adapter read-through can be identified with high sensitivity and specificity.<anchor xml:id="a26"/></p>
        <p><anchor xml:id="a27"/>For performance reasons, the actual algorithm combines these three tests. The adapter sequences are prepended to their respective reads, and then the combined read-with-adapter sequences from the pair are aligned against each other. A high-scoring alignment indicates that the first parts of each read are reverse complements, while the remaining parts of the reads match the respective adapters.<anchor xml:id="a28"/></p>
        <p>The alignment is implemented using a ‘seed and extend’ approach, similar to that in simple mode. Global alignment scoring is used to ensure an end-to-end match across the entire overlap.</p>
        <p>Figure 2 illustrates the alignments tested in palindrome mode. The process begins with an overlap between the adapters and the start of the opposite reads, as shown in (A). This alignment would detect a read pair containing no useful sequence information, which could be caused by the direct ligation of the adapters. Detection of this scenario would result in the dropping of both reads. Testing then proceeds by moving the relative positioning of the reads ‘backwards’, testing for increasingly longer valid DNA fragments, illustrated in (B). This scenario would result in the trimming of both reads as illustrated. Even when only a small fragment of the adapter is overlapping, as shown in (C), the overall alignment is easily sufficient to ensure reliable detection. The process is complete when the overlapping region no longer reaches into the adapters (D).</p>
        <p>Putative sequence alignments as tested in palindrome mode. The alignment process begins with the adapters completely overlapping the reads ( A ) testing for immediate ‘read-through’, then proceeds by checking for later overlap ( B ), including partial adapter read-through ( C ), finishing when the overlap indicates no read-through into the adapters ( D )</p>
        <p>The main advantage of palindrome mode is the longer alignment length, which ensures that the adapters can be reliably detected, even in the presence of read errors or where only a small number of adapter bases are present. If required, palindrome mode can be used to remove even a single adapter base, while retaining a low false-positive rate. We are aware of one other tool, AdapterRemoval ( Lindgreen, 2012 ), which independently developed a similar approach.</p>
        <p><anchor xml:id="a29"/>Note, however, because palindrome is limited to the detection of adapter read-through, a comprehensive strategy requires the combination of both simple and palindrome modes.<anchor xml:id="a30"/></p>
        <p>2.1.3 Alignment detection and scoring</p>
        <p>The algorithmic approach used for technical sequence alignments is somewhat unusual, avoiding the precalculated indexes often used in NGS alignments ( Li and Homer, 2010 ).</p>
        <p><anchor xml:id="a31"/>Initial sequence comparisons are done using a 16-base fragment from each sequence. The 16 bases are converted to the 64-bit integer, known as the seed, using a 4-bit code for each base: A = 0001, T = 0010, C = 0100 and T = 1000. These seeds are then compared using a bitwise-XOR, which determines which bits differ between the two seeds. This will result in a 0000 code for each matching base, and a code with two 1 s for each mismatch, e.g. 0011 for an A-T mismatch, as XOR(0001,0010) = 0011. The ‘1’s within this result are then counted using the ‘popcount’ operation, and this count will be exactly twice the number of differing bases for the 16-base fragments.<anchor xml:id="a32"/></p>
        <p>If the seeds are within the user-specified distance, the full alignment scoring algorithm is used. Matching bases are scored as , which is ∼0.602, while mismatches are penalized depending on their quality score, by , which can thus vary from 0 to 4. This results in a higher penalty for bases that are believed to be highly accurate.</p>
        <p><anchor xml:id="a33"/>‘Simple’ mode aligns each read against each technical sequence, using local alignment. This is implemented by finding the highest scoring region within the alignment, and thus may omit divergent regions on the ends.<anchor xml:id="a34"/></p>
        <p><anchor xml:id="a35"/>‘Palindrome’ mode aligns the forward and reverse reads, combined with their adapter sequences. It uses global alignment, which is the total alignment score of the overlapping region.<anchor xml:id="a36"/></p>
        <p>2.2 Quality filtering</p>
        <p><anchor xml:id="a37"/>Trimmomatic offers two main quality filtering alternatives. Both approaches exploit the Illumina quality score of each base position to determine where the read should be cut, resulting in the retention of the 5′ portion, while the sequence on the 3′ of the cut point is discarded. This fits well with typical Illumina data, which generally have poorer quality toward the 3′ end. These two approaches are described in the following sections.<anchor xml:id="a38"/></p>
        <p>2.2.1 Sliding Window quality filtering</p>
        <p><anchor xml:id="a39"/>The Sliding Window uses a relatively standard approach. This works by scanning from the 5′ end of the read, and removes the 3′ end of the read when the average quality of a group of bases drops below a specified threshold. This prevents a single weak base causing the removal of subsequent high-quality data, while still ensuring that a consecutive series of poor-quality bases will trigger trimming.<anchor xml:id="a40"/></p>
        <p>2.2.2 Maximum Information quality filtering</p>
        <p><anchor xml:id="a41"/>A novel alternative approach was motivated by the realization that, for many applications, the incremental value of retaining additional bases in a read is related to the read length. Intuitively, it is clear that short reads are almost worthless because they occur multiple times within the target sequence and thus they give only ambiguous information. Even at the risk of introducing errors, it is worthwhile to retain additional low-quality bases early in a read, so that the trimmed read is sufficiently long to be informative.<anchor xml:id="a42"/></p>
        <p><anchor xml:id="a43"/>However, beyond a certain read length, retaining additional bases is less beneficial, and may even be detrimental. Reads of moderate length are likely to be already informative and, depending on the task at hand, can be almost as valuable as full-length reads. Therefore, the smaller potential benefit of retaining additional bases must be balanced against the increasing risk of retaining errors, which could cause the existing read value to be lost.<anchor xml:id="a44"/></p>
        <p><anchor xml:id="a45"/>As such, it is worthwhile for the trimming process to become increasingly strict as it progresses through the read, rather than to apply a fixed quality threshold. To the best of our knowledge, this approach has not been applied in any existing tools.<anchor xml:id="a46"/></p>
        <p><anchor xml:id="a47"/>The ‘Maximum Information’ quality filtering approach implements this adaptive approach. It uses a combination of three factors to determine how much of each read should be retained.<anchor xml:id="a48"/></p>
        <p><anchor xml:id="a49"/>The first factor models the ‘length threshold’ concept, whereby a read must be of at least a minimal length to be useful for the downstream application. As described above, very short reads have little value, as they are too ambiguous to be informative. On the other hand, most long reads can be mapped to few locations in the target sequence. If they cannot be uniquely mapped, because of them originating in a repetitive region, it is unlikely that a small number of additional bases will resolve this. For reads between these extremes, the marginal benefit of a small number of additional bases is considerable, as these extra bases may make the difference between an ambiguous and an informative read.<anchor xml:id="a50"/></p>
        <p>A logistic curve was chosen to implement this scoring behavior, as it gives a relatively flat score for extreme values, while providing a steep transition around the user-specified threshold point. Given a target length t , the putative trimming to length l would give a length threshold score:</p>
        <p><anchor xml:id="a51"/>The second factor models ‘coverage’, and provides a linear score based on retained sequence length<anchor xml:id="a52"/>:</p>
        <p>This reflects that, given reasonably high-accuracy bases, a longer read contains more information that is useful for most applications.</p>
        <p><anchor xml:id="a53"/>The final factor models the ‘error rate’, and uses the error probabilities from the read quality scores to determine the accumulated likelihood of errors over the read.<anchor xml:id="a54"/> To calculate this score, we simply take the product of the probabilities that each base is correct, giving:</p>
        <p><anchor xml:id="a55"/>The correctness probabilities P corr of each base are calculated from the sequence quality scores. The error score typically begins as a high score at the start of the read, and depending on the read quality, typically drops rapidly at some point during the read.<anchor xml:id="a56"/></p>
        <p><anchor xml:id="a57"/>The Maximum Information algorithm determines the combined score of the three factors for each possible trimming position, and the best combined score determines how much of the read to trim. A user-specified strictness setting s , which can be set between 0 and 1, controls the balance between the ‘coverage’ factor (maximal for s = 0) and the ‘error rate’ factor (maximal for s = 1).<anchor xml:id="a58"/> This gives the following overall formula:</p>
        <p><anchor xml:id="a59"/>Figure 3 illustrates how the three factors are combined into a single score. The peak score is then used to determine the point where the read is trimmed.<anchor xml:id="a60"/></p>
        <p>How Maximum Information mode combines uniqueness, coverage and error rate to determine the optimal trimming point</p>
        <p>3 IMPLEMENTATION</p>
        <p><anchor xml:id="a61"/>Trimmomatic uses a pipeline-based architecture, allowing individual ‘steps’ (adapter removal, quality filtering, etc.) to be applied to each read/read pair, in the order specified by the user. Each step can choose to work on the reads in isolation, or work on the combined pair, as appropriate. The tool tracks read pairing and stores ‘paired’ and ‘single’ reads separately.<anchor xml:id="a62"/></p>
        <p>A full list of the additional trimming and filtering steps is given in the Supplementary Materials and the online manual.</p>
        <p>3.1 Convenience features</p>
        <p>Input and output files can be specified individually on the command line, but for paired-end mode, where two similarly named input and four similarly named output files are often used, a ‘template’ name can be given instead of the input and/or output files. This template is automatically expanded to give the complete set of files needed. See Supplementary Materials for more details.</p>
        <p>Compressed input and output are supported using either gzip or bzip2 formats. Compression/decompression is applied automatically when the appropriate file extensions are used, e.g. gz or bz2.</p>
        <p><anchor xml:id="a63"/>Performance can be improved using multiple threads if multiple CPU cores are available. The number of threads to use can be specified by the user or will be determined automatically if unspecified.<anchor xml:id="a64"/></p>
        <p><anchor xml:id="a65"/>Trimmomatic supports sequence quality data in both standard (phred+33) and Illumina ‘legacy’ formats (phred+64), and can also convert between these formats if required. The quality format is determined automatically if not specified by the user.<anchor xml:id="a66"/></p>
        <p><anchor xml:id="a67"/>The trimming status of each read can optionally be written to a log file. This is intended to help tune the choice of processing parameters used, but because it has a significant performance impact, it is not recommended unless needed.<anchor xml:id="a68"/></p>
        <p>4 RESULTS</p>
        <p><anchor xml:id="a69"/>To illustrate the value of data preprocessing, we evaluated two different scenarios: reference-based alignment using Bowtie 2 ( Langmead and Salzberg, 2012 ) and BWA ( Li and Durbin, 2009 ) against the Escherichia coli K-12/MG1655 reference (NCBI sequence NC_000913.2 ), and de novo assembly using Velvet ( Zerbino and Birney, 2008 ), on public E.coli K-12/MG1655 datasets (SRA datasets SRX131047 and SRR519926), as described in the Supplementary Methods .<anchor xml:id="a70"/></p>
        <p>4.1 Reference-based alignment</p>
        <p><anchor xml:id="a71"/>Dataset 1 (SRX131047) represents a typical Illumina library, sequenced on the HiSeq 2000 using 2 × 100 bp reads. Quality checking with FastQC revealed a notable quality drop in many reads after cycle 75 in both but did not report a high level of adapter contamination.<anchor xml:id="a72"/></p>
        <p><anchor xml:id="a73"/>In the reference-based scenario, preprocessing increased the number of uniquely aligned reads from dataset 1, as seen in the first portion of Table 1 . Filtering for both adapters and quality achieves the best result, and quality trimming is especially important when alignment settings are strict. The Maximum Information approach outperforms the Sliding Window approach in both cases, with a wider margin when the alignment mode is strict.<anchor xml:id="a74"/></p>
        <p>Results of alignment of raw data and data trimmed by Trimmomatic from both datasets</p>
        <p><anchor xml:id="a75"/>Notably, the optimal results for strict alignment and tolerant alignment were found using widely different quality stringency settings. (See Supplementary Results for more details.)<anchor xml:id="a76"/></p>
        <p><anchor xml:id="a77"/>To validate these results with an alternative aligner, we repeated the experiment using BWA. Although the alignment counts differ, because of slight differences between the tools in the settings or algorithms, the overall trend is similar. The best results are again achieved when filtering for both adapters and quality, as shown in the second part of Table 1 .<anchor xml:id="a78"/></p>
        <p><anchor xml:id="a79"/>Dataset 2 (SRR519926) is a 2 × 250 bp run, sequenced on an MiSeq. Although read quality is high at the start of each forward read, the longer read length allows more opportunity for errors to accumulate in the lower quality final 60–70 bases of each read. Furthermore, the reverse read has notably poorer quality, with quality dropping significantly by approximately base 120. These quality issues can be seen clearly in the FastQC plots, shown in the Supplementary Figure S1 , compared with the much higher average quality of the post-filtered data, as shown in Supplementary Figure S2 .<anchor xml:id="a80"/></p>
        <p><anchor xml:id="a81"/>Not surprisingly, trimming is even more critical to achieving acceptable alignment rates with these data. The final part of Table 1 shows that &lt;1.5% of the reads align in strict mode, which requires a perfect match, while just 7% of the reads can be aligned when allowing for one mismatch. Even with the liberal default settings, allowing nine mismatches, &lt;25% (197 933 reads) can be aligned. However, after trimming, almost 78% of the reads align perfectly.<anchor xml:id="a82"/></p>
        <p>4.2 De novo assembly</p>
        <p><anchor xml:id="a83"/>Both datasets also showed considerable improvement in a de novo assembly scenario. For the first dataset, the contig N50 size increased by 58% (95 389 versus 60 370 bp) after preprocessing, while the maximum contig size improved by ∼28%. Also, the assembly from unfiltered data contained a 34-bp perfect match to an adapter sequence, while no adapters were found in the filtered assemblies.<anchor xml:id="a84"/></p>
        <p><anchor xml:id="a85"/>The second dataset showed even greater benefits after trimming, with ∼77% improvement in N50 contig size (177 880 versus 100 662 bp) and ∼55% increase in maximum contig size. Perhaps surprisingly, no adapter sequences were found in the assembly of the untrimmed version of this dataset.<anchor xml:id="a86"/></p>
        <p>4.3 Comparison with existing tools</p>
        <p><anchor xml:id="a87"/>We also compared the performance of Trimmomatic with a variety of existing adapter and quality filtering tools in similar referenced-based scenarios, as described in the Supplementary Methods . The tools selected were AdapterRemoval ( Lindgreen, 2012 ), and Scythe/Sickle ( https://github.com/najoshi/ ), which fully support paired-end data and EA-Utils ( Aronesty, 2013 ), which maintains read pairing but loses singletons (reads whose mate has been filtered). Additionally, the single-end tools Cutadapt ( Martin, 2011 ), Fastx-Toolkit ( http://hannonlab.cshl.edu/fastx_toolkit ) and Reaper ( http://www.ebi.ac.uk/∼stijn/reaper ) were included.<anchor xml:id="a88"/></p>
        <p><anchor xml:id="a89"/>We filtered and aligned using paired-end mode for those tools that support it, but we used single-end mode as a fallback where necessary. In practice, ignoring pairing will result in suboptimal alignments but was done here in the interest of making the output of all tools comparable.<anchor xml:id="a90"/></p>
        <p><anchor xml:id="a91"/>Table 2 shows the output of the various tools aligned using Bowtie 2 in both tolerant and strict alignment settings. The top portion of this table, which shows the results using a tolerant alignment, suggests that the best tools perform almost identically in terms of output quality, with &lt;20 000 reads separating the top three, and most tools within ∼1% of the best. However, given that the unfiltered data show a difference of just 1.5%, the narrowness of the result is likely due to the relatively low rate of adapter contamination in this dataset, the high average read quality and the tolerant alignment settings used.<anchor xml:id="a92"/></p>
        <p>Results of Bowtie2 alignment of dataset 1 showing raw data and the trimmed data by each tool</p>
        <p><anchor xml:id="a93"/>The execution time varies widely, with EA-Utils leading, Trimmomatic following closely, while the remaining tools require considerably longer time. However, the testing methodology, using the median of 3 runs on a relatively small dataset, allows the entire dataset to be cached. In practice, it is likely that at least the faster tools will be limited by IO performance. The individual execution times for each run are shown in Supplementary Table S4 .<anchor xml:id="a94"/></p>
        <p>The equivalent alignment using strict mode, shown in the bottom part of the table, more clearly differentiates the tools, with the margin between Trimmomatic in Maximum Information mode and the alternatives widening considerably.</p>
        <p>Alignments of the same dataset using BWA painted a broadly similar picture, as shown in the top half of Table 3 , although the difference between strict and tolerant mode is not so strong. Again, Maximum Information mode appears to outperform by a greater margin for stricter alignments.</p>
        <p>Results of strict and tolerant BWA alignments of the raw data and trimmed data from each tool (using both quality modes for Trimmomatic) from both datasets</p>
        <p><anchor xml:id="a95"/>The results of dataset 2, shown in the lower half of Table 3 , rank many of the tools differently, with AdapterRemoval dropping significantly in the ranking. Trimmomatic remains the best performer, especially in Maximum Information mode, but Cutadapt becomes the closest challenger. Reaper was unable to process this dataset, perhaps because of the long read length.<anchor xml:id="a96"/></p>
        <p>5 DISCUSSION</p>
        <p>5.1 The need for read preprocessing</p>
        <p><anchor xml:id="a97"/>We have illustrated the advantages of NGS data preprocessing in both reference-based and de novo assembly applications. For high-quality datasets, in reference-based applications, the benefits of preprocessing seem somewhat limited. We show ∼1.5% gain in unique alignments shown if mismatch tolerant aligner settings are used, although a more substantial difference could be seen when perfect matches were required. In practice, however, given a high-quality dataset like this, the benefits to a downstream application such as variant calling are likely to be small.<anchor xml:id="a98"/></p>
        <p><anchor xml:id="a99"/>The second dataset, which had reads with substantially lower quality, illustrated that even reference-based tasks can benefit substantially from read preprocessing. Less than 25% of reads could be aligned by BWA without preprocessing. This could be improved to almost 80% by preprocessing, with almost 78% aligning even with strict settings.<anchor xml:id="a100"/></p>
        <p><anchor xml:id="a101"/>In the de novo assembly scenario, trimming was needed to ensure adapter sequences would not be incorporated into the newly assembled genome. This benefit was accompanied by a significant 58%/77% improvement in N50, respectively, and 28%/55% improvement, respectively, in maximum contig size for two datasets. The substantial improvement in assembly statistics further justifies the preprocessing of reads for de novo assembly.<anchor xml:id="a102"/></p>
        <p><anchor xml:id="a103"/>It is perhaps not surprising that preprocessing is so beneficial to de novo assembly, as many assembly tools, including velvet, do not exploit quality scores and thus treat all data equally, regardless of the known difference in quality. The effect of adapter sequences is also more serious, given the risk of incorporating adapter sequences into the final sequence assembly, compared with the mere reduction in the alignment rate typically seen in reference-based approaches.<anchor xml:id="a104"/></p>
        <p>5.2 Comparison against existing tools</p>
        <p><anchor xml:id="a105"/>Trimmomatic compared favorably against all other tools in the tests performed.<anchor xml:id="a106"/></p>
        <p>When using high-quality raw data and liberal alignment criteria, the differences between the tools were relatively small. In this scenario, AdapterRemoval performed particularly well, reflecting its relative strength in removing technical sequences. This is unsurprising because, to the authors’ knowledge, AdapterRemoval is the only other tool to implement a pair-aware adapter removal strategy.</p>
        <p><anchor xml:id="a107"/>Nonetheless, the use of strict alignment criteria, especially when combined with poor-quality input data, allows the differences between the tools to become clearer. In these scenarios, appropriate trimming based on quality seems to be more important, whereas technical sequence identification appeared to matter less. This helps explain the change in relative rankings of the tools between the two datasets. Trimmomatic with the Maximum Information mode seems to perform exceptionally well in these challenging scenarios.<anchor xml:id="a108"/></p>
        <p>Funding : We want to thank the BMBF for funding through grants 0315702F, 0315961 and 0315049A and BLE/BMELV Verbundprojekt: G 127/10 IF.</p>
        <p>Conflict of Interest : none declared.</p>
        <p>Supplementary Material</p>
        <p>REFERENCES</p>
        <p>Associated Data</p>
        <p>Supplementary Materials<anchor xml:id="a109"/></p>
    </body>
  </text>
</TEI>
