This is the command daligner that can be run in the OnWorks free hosting provider using one of our multiple free online workstations such as Ubuntu Online, Fedora Online, Windows online emulator or MAC OS online emulator
daligner - long read aligner
daligner [-vbAI][-kint(14)] [-wint(6)] [-hint(35)] [-tint] [-Mint] [-edouble(.70)]
[-lint(1000)] [-sint(100)] [-Hint] [-mtrack]+ subject:db|dam target:db|dam ...
Compare sequences in the trimmed subject block against those in the list of target blocks
searching for local alignments involving at least -l base pairs (default 1000) or more,
that have an average correlation rate of -e (default 70%). The local alignments found
will be output in a sparse encoding where a trace point on the alignment is recorded every
-s base pairs of the a-read (default 100bp). Reads are compared in both orientations and
local alignments meeting the criteria are output to one of several created files described
below. The -v option turns on a verbose reporting mode that gives statistics on each
major step of the computation.
The options -k, -h, and -w control the initial filtration search for possible matches
between reads. Specifically, our search code looks for a pair of diagonal bands of width
2^w (default 2^6 = 64) that contain a collection of exact matching k-mers (default 14)
between the two reads, such that the total number of bases covered by the k-mer hits is h
(default 35). k cannot be larger than 32 in the current implementation. If the -b option
is set, then the daligner assumes the data has a strong compositional bias (e.g. >65% AT
rich), and at the cost of a bit more time, dynamically adjusts k-mer sizes depending on
compositional bias, so that the mers used have an effective specificity of 4^k.
If there are one or more interval tracks specified with the -m option, then the reads of
the DB or DB's to which the mask applies are soft masked with the union of the intervals
of all the interval tracks that apply, that is any k-mers that contain any bases in any of
the masked intervals are ignored for the purposes of seeding a match. An interval track
is a track, such as the "dust" track created by DBdust, that encodes a set of intervals
over either the untrimmed or trimmed DB.
Invariably, some k-mers are significantly over-represented (e.g. homopolymer runs).
These k-mers create an excessive number of matching k-mer pairs and left unaddressed would
cause daligner to overflow the available physical memory. One way to deal with this is to
explicitly set the -t parameter which suppresses the use of any k-mer that occurs more
than t times in either the subject or target block. However, a better way to handle the
situation is to let the program automatically select a value of t that meets a given
memory usage limit specified (in Gb) by the -M parameter. By default daligner will use
the amount of physical memory as the choice for -M. If you want to use less, say only 8Gb
on a 24Gb HPC cluster node because you want to run 3 daligner jobs on the node, then
specify -M8. Specifying -M0 basically indicates that you do not want daligner to self
adjust k-mer suppression to fit within a given amount of memory.
For each subject, target pair of blocks, say X and Y, the program reports alignments where
the a-read is in X and the b-read is in Y, and vice versa. However, if the -A option is
set ("A" for "asymmetric") then just overlaps where the a-read is in X and the b-read is
in Y are reported, and if X = Y, then it further reports only those overlaps where the
a-read index is less than the b-read index. In either case, if the -I option is set ("I"
for "identity") then when X = Y, overlaps between different portions of the same read will
also be found and reported.
Each found alignment is recorded as -- a[ab,ae] x bo[bb,be] -- where a and b are the
indices (in the trimmed DB) of the reads that overlap, o indicates whether the b-read is
from the same or opposite strand, and [ab,ae] and [bb,be] are the intervals of a and bo,
respectively, that align. The program places these alignment records in files whose name
is of the form X.Y.[C|N]#.las where C indicates that the b-reads are complemented and N
indicates they are not (both comparisons are performed) and # is the thread that detected
and wrote out the collection of alignments contained in the file. That is the file
X.Y.O#.las contains the alignments produced by thread # for which the a-read is from X and
the b-read is from Y and in orientation O. The command daligner -A X Y produces 2*NTHREAD
thread files X.Y.?.las and daligner X Y produces 4*NTHREAD files X.Y.?.las and Y.X.?.las
(unless X=Y in which case only NTHREAD files, X.X.?.las, are produced).
By default, daligner compares all overlaps between reads in the database that are greater
than the minimum cutoff set when the DB or DBs were split, typically 1 or 2 Kbp. However,
the HGAP assembly pipeline only wants to correct large reads, say 8Kbp or over, and so
needs only the overlaps where the a-read is one of the large reads. By setting the -H
parameter to say N, one alters daligner so that it only reports overlaps where the a-read
is over N base-pairs long.
While the default parameter settings are good for raw Pacbio data, daligner can be used
for efficiently finding alignments in corrected reads or other less noisy reads. For
example, for mapping applications against .dams, we run
daligner -k20 -h60 -e.85
and on corrected reads, we typically run
daligner -k25 -w5 -h60 -e.95 -s500
and at these settings it is very fast.
Use daligner online using onworks.net services