Provided by: seqprep_1.3.2-5_amd64 
NAME
seqprep - merge paired end Illumina reads
SeqPrep is a program to merge paired end Illumina reads that are overlapping into a single
longer read. It may also just be used for its adapter trimming feature without doing any
paired end overlap.
USAGE
seqprep required args [options]
Required Arguments:
-f <first read input fastq filename>
-r <second read input fastq filename>
-1 <first read output fastq filename>
-2 <second read output fastq filename>
General Arguments (Optional):
-3 <first read discarded fastq filename>
-4 <second read discarded fastq filename>
-h Display this help message and exit (also works with no args)
-6 Input sequence is in phred+64 rather than phred+33 format, the output will still be phred+33
-q <Quality score cutoff for mismatches to be counted in overlap; default = 13>
-L <Minimum length of a trimmed or merged read to print it; default = 30>
Arguments for Adapter/Primer Trimming (Optional):
-A <forward read primer/adapter sequence to trim as it would appear at the end of a read (recommend about 20bp of this)
(should validate by grepping a file); default (genomic non-multiplexed adapter1) = AGATCGGAAGAGCGGTTCAG>
-B <reverse read primer/adapter sequence to trim as it would appear at the end of a read (recommend about 20bp of this)
(should validate by grepping a file); default (genomic non-multiplexed adapter2) = AGATCGGAAGAGCGTCGTGT>
-O <minimum overall base pair overlap with adapter sequence to trim; default = 10>
-M <maximum fraction of good quality mismatching bases for primer/adapter overlap; default = 0.020000>
-N <minimum fraction of matching bases for primer/adapter overlap; default = 0.870000>
-b <adapter alignment band-width; default = 50>
-Q <adapter alignment gap-open; default = 8>
-t <adapter alignment gap-extension; default = 2>
-e <adapter alignment gap-end; default = 2>
-Z <adapter alignment minimum local alignment score cutoff [roughly (2*num_hits) - (num_gaps*gap_open) - (num_gaps*gap_close) - (gap_len*gap_extend) - (2*num_mismatches)]; default = 26>
-w <read alignment band-width; default = 50>
-W <read alignment gap-open; default = 26>
-p <read alignment gap-extension; default = 9>
-P <read alignment gap-end; default = 5>
-X <read alignment maximum fraction gap cutoff; default = 0.125000>
Optional Arguments for Merging:
-y <maximum quality score in output ((phred 33) default = ´]´ )>
-g <print overhang when adapters are present and stripped (use this if reads are different length)> - UNIMPLEMENTED
-s <perform merging and output the merged reads to this file>
-E <write pretty alignments to this file for visual Examination>
-x <max number of pretty alignments to write (if -E provided); default = 10000>
-o <minimum overall base pair overlap to merge two reads; default = 15>
-m <maximum fraction of good quality mismatching bases to overlap reads; default = 0.020000>
-n <minimum fraction of matching bases to overlap reads; default = 0.900000>
NOTE 1: The output is always gziped compressed.
NOTE 2: If the quality strings in the output contain characters less than asciii 33 on an
ascii table (they look like lines from a binary file), try running again with or without
the -6 option.
SETUP
When an adapter sequence is present, that means that the two reads must overlap (in most
cases) so they are forcefully merged. When reads do not have adapter sequence they must be
treated with care when doing the merging, so a much more specific approach is taken. The
default parameters were chosen with specificity in mind, so that they could be ran on
libraries where very few reads are expected to overlap. It is always safest though to save
the overlapping procedure for libraries where you have some prior knowledge that a
significant portion of the reads will have some overlap.
Before running SeqPrep make sure to check that the program´s defaults are indeed the
adapters you are looking for. Try copying the default forward adapter from this file and
grep it against your reads doing a word count, also try the same with the reverse adapter
with grep. You should see some hits. You can also try using (and validating with grep) -A
GATCGGAAGAGCACACG -B AGATCGGAAGAGCGTCGT as parameters. To find a list of Illumina adapter
sequences you should write to Illumina tech support TechSupport@illumina.com (they do not
like people to share the list of sequences outside of their institution).
Choose about 20bp of an adapter sequence where:
1. You see the most hits with grep.
2. When you run a command like zcat Lane2_0d_2.fastq.gz | head -n 1000000 |grep "INSERT
ADAPTER HERE" | head you see the adapter sequence show up at the beginning of a few
reads. Also the -A and -B arguments should be as they show up in your data, SeqPrep
searches directly for these sequences without doing reverse complementing
3. Check the forward and reverse and make sure that you have roughly the same number of
hits via a command to count hits like: zcat Lane2_0d_2.fastq.gz | head -n 1000000
|grep "INSERT ADAPTER HERE" | wc -l As an additional precaution, the program checks
for good read overlap once the adapters are trimmed. If the adapter is trimmed and the
reads do not have a reasonable adapter overlap (you can modify this setting with -X)
then the reads aren´t printed or merged.
See Test/README.md for some information on testing out other parameters. Test/SimTest has
some particularly cool test data which you can use to check out sensitivity and
specificity of adapter trimming using different parameters. The results of the test are
displayed in results.html which uses the google charts API so that the points are
interactive and you can easily determine which settings made which points.
LOW COMPLEXITY ALIGNMENTS
My current strategy to deal with ambiguous alignments to low complexity regions is as
follows:
I have some minimum requirements for an overlap to be accepted After the first one is
found (ie the one with the maximal overlap between the two sequences), if low complexity
filtering is enabled, I keep searching if a second viable hit is found, I give up and say
that it is not a good idea to merge the two reads. I check for ambiguous alignments in
read overlapping, but not in adapter trimming where the most conservative thing to do is
strip the most aggressively aligned adapter (The closest to the beginning of the read).
To accept an alignment I allow some fraction of mismatches (currently the floor of 0.06 of
the alignment length for adapter and 0.02 of the alignment length for two reads). That
means that in most cases for overlapping two reads I don´t allow any mismatches between
adjacent reads, but if there is a 50bp potential overlap with 1 mismatch over q20 for
example, I allow it. Anything below 50 needs to be perfect other than with low quality
bases.
Since we ignore poor quality bases, we could have the case where a single real match
followed by a long string of poor quality bases to the end of the read would result in a
called overlap. That seemed like a bad idea. To get around that I require that at least
some fraction of the overlapping length be matches. Right now I have that parameter set at
0.7 for adapter trimming and 0.75 for read merging, so for a case where only the last 10
bases overlap, at least 7 of those must be matches.
Since doing that many floating point multiplications seems like a bad idea, I just have a
table that pre-calculates all of those min matches and max mismatch numbers for every
overlap length up to the maximum allowed read length.
Finally I have a parameter you can set which specifies a minimum resulting read length
after adapter trimming and/or merging so that ultra short trimmed reads aren´t output.
Following are results from hand testing the three main merge cases. Now to generate
similar output automatically just supply the -E readable_alignment.txt.gz argument to the
program (the output is gzip compressed into the file name specified).
Sequence Merge No Adapter Present:
QUER: NCCTGCTACTACCACCCGTTCCGTGCCTGGAGCCTGCATGTTGGGCAGATACGTGCTGCCACAGCCTGTCTCTGCTGGTGCCTGGGCCTC
|| |||||||||||| || | |||||||||||||||||||||||||||||||||
SUBJ: TGTGTGTTGGGCAGATGCGGGGGGCCACAGCCTGTCTCTGCTGGTGCCTGGGCCTCTCCTGTTCCTTGCCCACGTCTCCGTCTCCTGTTG
RESU: NCCTGCTACTACCACCCGTTCCGTGCCTGGAGCCTGCATGTTGGGCAGATACGTGCTGCCACAGCCTGTCTCTGCTGGTGCCTGGGCCTCTCCTGTTCCTTGCCCACGTCTCCGTCTCCTGTTG
Quality Merge:
QUER: !223387787@@@CCC22C@@@@@@@@@@@@@@@@@@@@@@@@@@@@?@@89887:::::.2125@@:@@:::::@@@@@<<::8@@@@@
SUBJ: !!!!!!!!!!!!!!!!!!!!!!!!!!!@@@8DEGE@EDDBB2<BBE@EHBFE@EE>D8@DBE>BFIDH@IIEEIIBEIEIIGBIIGIFII
RESU: !223387787@@@CCC22C@@@@@@@@@@@@@@@@@@@@@@@@@@@@?@@89887:::::.QPQLSSSSSSSSSSQSSSSSSSSSSSSSSD8@DBE>BFIDH@IIEEIIBEIEIIGBIIGIFII
Sequence Merge Adapter Present, Easy Peezy Mode (same lengths):
SUBJ: NGATATGATTCCCAATCTAAGCAAACTGTCATGGAAAC
|||||||||||||||||||||||||||||||||||||
QUER: GGATATGATTCCCAATCTAAGCAAACTGTCATGGAAAC
RESU: GGATATGATTCCCAATCTAAGCAAACTGTCATGGAAAC
Quality Merge:
SUBJ: !.-/.53444@@@@@@@@@@@@@@@@@@@@@@@@@@@@
QUER: IHGIIIDIIHGEHIGHIFHIFIIIIHIIIIIIIIIHII
RESU: ISSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
Sequence merge Adapter but lengths differ:
SUBJ: AATTGATGGGTGCCCACCCACGGGCCAGACAAAATCATCTGGCAAGCTGGATGCAGCCTACAAGCTGTAAGATTGGA
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
QUER: AATTGATGGGTGCCCACCCACGGGCCAGACAAAATCATCTGGCAAGCTGGATGCAGCCTACAAGCTGTA
RESU: AATTGATGGGTGCCCACCCACGGGCCAGACAAAATCATCTGGCAAGCTGGATGCAGCCTACAAGCTGTAAGATTGGA
Quality Merge:
SUBJ: =DEC??DDBD?4B=BEE@@@GB>GEE:DE8=2::6GDGBGEGDD<=;A?=AGGGG=5.=<BD?B?DDB>B4725:E>
QUER: GDDBBFBGGFBHFIEDGGGBDGGG<GGDDG@IIIEIHDIHGIIIDDGDGDFDIFIHGIDEGGGDIIIGI
RESU: SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSB4725:E>
If interested there is a website where I post my tests of different parameters for SeqPrep
on simulated data. There are also a few comparison stats of different programs to trim
adapters. The website can be accessed here: http://hgwdev.cse.ucsc.edu/~jstjohn/seqprep/
where the pages are named result(date).html. The latest ones (as of when I have gotten
around to edit this) can be found here:
http://hgwdev.cse.ucsc.edu/~jstjohn/seqprep/results2011-09-15.html
Note that although my program is more sensitive and specific than fastq-clipper, I
optomized my default parameters based on this test. Results on real data may be different,
although I believe my method takes advantage of a more realistic adapter model than other
software does. For example, even though my program requires 10bp of adapter to be present
at the end of a read to trim it off (by default) there is a backup adapter trimming
function that trimms based on strong and unambiguous read overlap. Because of this my
program can trim the adapter even if it is only present in the last few bases of the read.
Also note that fastq-mcf appears to do a little better at sensitivity (0.992 vs 0.985) at
a very large cost to specificity (0.497 vs 0.994).
AUTHOR
○ All content by John St. John
○ Manpage edited for Debian by Tim Booth