Trimming unmatched sequence on 3' end of reads

[Jenni McIntyre]

Hi,

I have just run PEAR on my data which had a fragment length shorter than the read length. 

I had previously used cutadapt to trim 3' adapter sequence, demultiplex the reads using inline barcodes at the 5' end and then demultiplex loci using the primer sequence at the 5' end. 

I still have reads therefore that are like this: 

5' mysequence_primersequence_inlinebarcode 3'

An initial look at the first few lines in the output fastq files show that PEAR has merged the reads for my locus, but has discarded the 3' unmatched regions (the primerseqence_inlinebarcode). 

This is fine, but I want to be sure that it will have consistently done this (i.e. that it is part of the program algorithm) before I continue simply assuming that it has. 

Does PEAR always discard 3' unmatched read, even if good quality?

It's not clear from the paper/manual/github.

Thanks,

Jenni