I am presently analysing 300 bp paired-end Illumina reads, and after some generous trimming (with Trimmomatic), the remaining 200 bp have excellent base sequence quality all the way (FastQC). However, when I merge the resulting P1 and P2 outfiles (forward and reverse paired reads) in PANDAseq, a large section in the middle gets horrible base qualities, with very wide confidence intervals and subsequent programs throwing out most of the reads because they "contain at least one poor base". I would have thought that the central portion of the reads should be best because it gets information from both P1 and P2. Does anyone have an explanation/solution for this?
Thanks, Peter
In case anyone is interested in the command lines:
java -jar trimmomatic-0.36.jar PE -trimlog trimlog.txt HorS_R1.fastq HorS_R2.fastq -baseout HorS_ClipMaxCropHeadcrop ILLUMINACLIP:ezRAD_R1R2adapters.fa:2:30:10:2 HEADCROP:20 CROP:200 MAXINFO:50:0.8 MINLEN:50
pandaseq -f HorS_ClipMaxCropHeadcrop_1P.fastq -r HorS_ClipMaxCropHeadcrop_2P.fastq -A pear -B -N -F -g logfile.txt > HorS_ClipMaxCropHeadcrop_pear.fastq
Running only the 1P outfile in the subsequent program (AftrRAD) produces excellent results, but it bothers me that we're losing a third of the data set.
When you merge the reads is the insert size taken into account? Are P1 and P2 identical? I would imagine that any mismatches may result in a reduced quality score.
Fiona has a good point. If the program is assuming for example a 700bp insert size, than merged reads will have be filled in with Ns in between your p1 and p2 reads. Might look into that
- Badges
- Science topic
- Similar topics
- Phytochemistry
- Extracts