Open marcelm opened 2 years ago
Thanks for reporting, this is indeed a problem that should be fixed.
Some notes to myself and/or those interested in the details.
--no-indels
, which uses a different algorithm.ADAPTER
will be found in PTERSEQUENCE
, but not in SEQUENCEADAPT
. This is necessary because otherwise short, random matches at the 3' end would lead to the entire read being trimmed. It is also symmetrical to how 3' adapters are aligned. (For those, partial occurrences at the 5' end are not allowed.)One test case that should work is to find a regular 5' adapter ADAPTER
, allowing 1 error (ignoring error rate), within TADAPT
. The alignment could look like this:
ADAPTER
TADAP-
Thank you @marcelm
Yes, you can use the anywhere
adapter-trimming parameter. Just write -a 'ALONGADAPTOR;anywhere'
. This works:
$ echo -e '>r\nADAPTORGGGGGGGGGGGGGGGGGG' | cutadapt -N --quiet -a 'ALONGADAPTOR;anywhere' -
>r
(The third example, as you gave it, will actually work because the error rate is by default 0.1, which will allow to delete the initial L
.)
thank you very much. I found this argument in the document now. 😂
On Fri, Oct 1, 2021, 04:14 Marcel Martin @.***> wrote:
Yes, you can use the anywhere adapter-trimming parameter. Jus twrite -a 'ALONGADAPTOR;anywhere'. This works:
$ echo -e '>r\nADAPTORGGGGGGGGGGGGGGGGGG' | cutadapt -N --quiet -a 'ALONGADAPTOR;anywhere' -
r
(The third example, as you gave it, will actually work because the error rate is by default 0.1, which will allow to delete the initial L.)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcelm/cutadapt/issues/565#issuecomment-932061737, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJKEVU3HLBS5EHXERAXBT3UEV3YXANCNFSM5EGRYBUA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
HI @marcelm
Is this issue solved?
No, sorry, I haven’t prioritized it.
Given a sequence with 5' adapter, eg ALONGADAPTORsequence, if sequence is low quality in the end, or has polyG, cutadapt will trim this sequence into ALONGADAPTORseq (1st case) or ALONGADAP (2nd case). Then the
-g
argument and remove the adapter in the 1st case, but not in the 2nd case. And will cause adaptor contamination in the filtered reads.Originally posted by @yech1990 in https://github.com/marcelm/cutadapt/issues/550#issuecomment-921100958