NAME

       daligner - long read aligner

SYNOPSIS

       daligner   [-vbAI][-kint(14)]   [-wint(6)]  [-hint(35)]  [-tint]  [-Mint]  [-edouble(.70)]
       [-lint(1000)] [-sint(100)] [-Hint] [-mtrack]+ subject:db|dam target:db|dam ...

DESCRIPTION

       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.

SEE ALSO

       LAsort(1) LAmerge(1) LAshow(1) LAcat(1) LAsplit(1) LAcheck(1) HPCdaligner(1) HPCmapper(1)