n+1 cycles - how do you deal with it

[fanli]

Per Illumina, we use n+1 cycles for n-bp read lengths (e.g. 2x151 cycles for 2x150bp reads). Out of curiosity, how do other sequencing providers typically handle that last +1 base? Do you:
1) include the +1 base in your FASTQ output and let clients deal with it?
2) trim after demultiplexing (e.g. using Trimmomatic)?
3) mask during demultiplexing (e.g. using --use-bases-mask)
4) other...?

A bit of background, we use both MiSeq and Nextseq instruments, and have resorted to manually running bcl2fastq.

[Brian Bushnell]

Here's an error-rate profile for 2x151bp Illumina reads from a HiSeq:



Note how the error rate spikes at base 151. For all of our processing, I trim that last base.

BBDuk has a flag "ftm", which stands for "force-trim modulo"; I generally run with "ftm=5". This will trim every read so that the length is equal to zero modulo 5. In other words, 76bp reads are trimmed to 75; 101 ->100; 151 -> 150; 251 -> 250; and 301 -> 300. It's convenient for an automated pipeline because it works regardless of the length, and if the reads come out as 2x150 instead of 2x151, then it won't trim them.

"ftm" is applied before adapter-trimming, which increases the ability to detect adapter sequences, as there will be fewer mismatches on average.

[fanli]

Do you/clients/collaborators ever want the +1 base for any purpose? I guess I'd lean towards using bcl2fastq to drop it during demux..

[Brian Bushnell]

The sooner you drop it, the more efficient, so dropping it during demux is ideal. There are always people who will want anything, but it will only cause them problems in analysis. I consider it an artifact of sequencing that is necessary to achieve length N reads. Just don't tell them about it, and give them 2x150bp reads when they order 2x150bp reads... problem solved.