Hi, great software but I noticed a problem with undersensitive 3' quality trimming (using the --cut_tail option) compared to other popular trimmers (cutadapt, bbduk). I traced this to the order of operations, specifically with poly-G trimming occurring after quality trimming. 3' strings of Gs from 2-color platforms like the NextSeq indicating no signal are often high quality, even in reads that are otherwise junky or have low quality 3' ends, and therefore will protect these reads from proper 3' quality trimming. Running fastp twice sequentially, first to trim poly-G and second to trim low quality 3' bases, completely fixes the problem. So it would be best to move poly-G trimming up in the order of operations, before quality trimming. (And poly-X trimming, if desired, will still eliminate any poly-G strings that remain after quality trimming.)
Using a left-to-right sliding window (--cut_right) mitigates this somewhat but creates other problems with overtrimming and isn't a great solution unless this behavior is specifically what one wants. (Ideally it would be great to add an option to use the Phred/Mott algorithm instead of a sliding window, but that's a separate issue.)
Thanks!
Hi, great software but I noticed a problem with undersensitive 3' quality trimming (using the
--cut_tailoption) compared to other popular trimmers (cutadapt, bbduk). I traced this to the order of operations, specifically with poly-G trimming occurring after quality trimming. 3' strings of Gs from 2-color platforms like the NextSeq indicating no signal are often high quality, even in reads that are otherwise junky or have low quality 3' ends, and therefore will protect these reads from proper 3' quality trimming. Running fastp twice sequentially, first to trim poly-G and second to trim low quality 3' bases, completely fixes the problem. So it would be best to move poly-G trimming up in the order of operations, before quality trimming. (And poly-X trimming, if desired, will still eliminate any poly-G strings that remain after quality trimming.)Using a left-to-right sliding window (
--cut_right) mitigates this somewhat but creates other problems with overtrimming and isn't a great solution unless this behavior is specifically what one wants. (Ideally it would be great to add an option to use the Phred/Mott algorithm instead of a sliding window, but that's a separate issue.)Thanks!