Removing adapters but keep sequence after the adapter

[JBauer]

Hi there,
I have a particular library to analyse that pose a problem when trying to remove the adapters. The way the library was constructed require us to use "flash" to identify overlapping pair and merge them. This can results in a adapter being rebuild in the middle of the merged sequence.
Does anyone knows of a tool that will clip the adapter out and leave both side of the adapter?
I have tried cutadapt, FASTX but none seems to be able to keep both side of the adapter.
Thanks.

[Brian Bushnell]

I don't really understand the situation. What kind of library construction was used, and what kind of adapters? When an adapter is found in a read, from a normal fragment library, the sequence to the left of the adapter is genomic and to the right is random junk that you want to discard.

That said... you CAN mask the adapter and keep everything on both sides with BBDuk:

bbduk.sh in=reads.fq out=masked.fq kmask=N ref=adapters.fa k=25 hdist=1

But, I don't think that's really what you want to do. It might help if you could post an example of one of the read pairs in question both before and after merging.

Flash's defaults are very aggressive and result in a high false-positive merge rate; also, older versions of Flash had problems correctly merging reads that had an insert size shorter than read length (i.e., they had adapter sequence). So, perhaps you should try the most recent version of Flash and reduce the sensitivity, or an alternative like BBMerge, and see if the problem goes away.

[JBauer]

I don't really understand the situation. What kind of library construction was used, and what kind of adapters? When an adapter is found in a read, from a normal fragment library, the sequence to the left of the adapter is genomic and to the right is random junk that you want to discard.

That said... you CAN mask the adapter and keep everything on both sides with BBDuk:

bbduk.sh in=reads.fq out=masked.fq kmask=N ref=adapters.fa k=25 hdist=1

But, I don't think that's really what you want to do. It might help if you could post an example of one of the read pairs in question both before and after merging.

Flash's defaults are very aggressive and result in a high false-positive merge rate; also, older versions of Flash had problems correctly merging reads that had an insert size shorter than read length (i.e., they had adapter sequence). So, perhaps you should try the most recent version of Flash and reduce the sensitivity, or an alternative like BBMerge, and see if the problem goes away.

Thanks for the advice. I know that usually anything to the left is to be thrown away but I am not sure in this case as I get more than half of the read sometime on the left of the adapter, and it doesn't seem to match any of the adapter sequences. We have been warned that they noticed this in the past due to the way they are making the library. I will try what you are suggesting and see if it makes any difference.