Trimming adaptor sequences counts

[cnluzon]

I have a question about the way cutadapt removes adaptor sequences. I see this table in the results of one recent run:

Overview of removed sequences
length  count   expect  max.err error counts
3       1380352 1004680.1       0       1380352
4       510013  251170.0        0       510013
5       188447  62792.5 0       188447
6       129181  15698.1 0       57978 71203
7       351126  3924.5  1       25914 325212

My question is whether length means length of the sequence trimmed, and if so, isn't that a very short match for a 34bp search?

[marcelm]

If the adapter is specified as a “regular 3’ adapter” (using option -A), then partial matches are allowed. Since the sequence that is searched for is TTTTTCTTTTCTTTTTTCTTTTCCTTCCTTCTAA, we get an adapter match if a read ends with TTT, TTTT, TTTTT or TTTTTC, TTTTTCT etc. This is meant for finding adapters ligated to the 3’ end of a variable-length molecule because then then the read isn’t guaranteed to cover the entire adapter. If I remember correctly, the nature of that contaminant sequence was a bit unclear, so it’s possible this should be done somehow differently.

Considering that we use --discard-trimmed, which means that we throw away any read that has a match, even a short partial one, we should probably increase the minimum overlap length (option -O). Depending on what you want to achieve, it can be set to the length of the sequence to avoid partial matches entirely.

[marcelm]

@cnluzon Do you think we should increase the minimum overlap length as I suggested or should this issue just be closed?

[cnluzon]

Somehow I missed this issue for a very long time, so far it seems to have worked just fine as it is, but I wonder if @simonelsasser has some comments on this?