version 2.2

[Julian Catchen]

Hi All,

We have made a minor release today, Stacks version 2.2. The main change
is that we added support for the BestRAD protocol (Ali, et al. 2016) in
process_radtags. In BestRAD, the barcode/cutsite can be on either the
single or paired-end read and, when enabled, process_radtags will flip
the order of the reads so the barcode/cutsite is always properly on the
single-end read.

Best,

julian

Stacks 2.2 - Aug 22, 2018
--------------------------
Feature: Added the --bestrad flag to process_radtags. When used it will
look for reads that need transposed before they are processed.

Feature: gstacks: New option --max-debrujin-reads to control the
construction of the de Bruijn graph; replaces --min-kmer-freq which is
now deprecated

Bugfix: Added run number to output FASTQ headers in process_radtags to
make sure read IDs are always unique.

[Amanda Stahlke]

Hi Julian and all,

The bestrad flag works great! Very cool to see this in action.

I'd like to suggest one more improvement, as we're realizing that the beginning of the reads sometimes have errors, and don't have the anticipated GG-start (eg NG or GC). Currently I think those errors are rescued as mismatches in the barcode. The barcodes I supply always have GG starts. It might be nice to allow an error in the actual barcode itself instead of that sensitive GG start.

One option is to trim the first two bases (https://groups.google.com/d/msg/stacks-users/4KxNNU-dgEs/L4pLJHwRBAAJ). Another could be to require process_radtags to skip the first two bases of a read with the --bestrad flag.

What do you think? Worth updating the --bestrad flag? Should I stick to mismatches in the barcode? Or try trimming all reads? 

Thanks!

Amanda

[John Chau]

Hello, 

How does the 'bestrad' function work with the 'adapter' function? I.e., is 'adapter-1' always checked for in the original single-end read, regardless of which read the barcode/cutsite is found on?

Thanks for any advice.

Best,

John