# Haplotag data

Linked-read sequencing exists to combine the throughput and accuracy of short-read sequencing with the long range haplotype information of long-read sequencing. Haplotagging is an implementation of linked-read sequencing developed by Meier et al. to:

1. sequence a large number of samples
2. achieve high molecular resolution
3. do both within a reasonable budget

If you don't have haplotagged data, you can simulate some and try it out! Otherwise, Harpy will likely be of little to no use to you. See the haplotagging site for more information about haplotagging and why you might consider it for your study system.

While barcodes are actually combinatorial bases, in the read headers they are represented with the format AxxCxxBxxDxx, where each barcode segment is denoted as Axx (or Bxx, etc.). The capital letter denotes which preparation microwell plate the barcode segment is from (plate A, B, C, or D) and xx is a number between 00 and 96 corresponding to the well from that microplate. So, the A14 segment would correspond with the barcode from Plate A, well 14. A 00 barcode (e.g. C00) indicates a missing/invalid barcode segment, which invalidates the entire barcode.

If you think haplotagging is as simple as exactly 96^4 unique barcodes, you would only be half-correct. The original haplotagging protocol in Meier et al. is good, but the authors (and others) have been working to improve this linked-read technology to improve things like reduce PCR duplicates, improve successful barcode sequencing and error correction, etc. As a result, a few updated variants of the beadtags will appear, each likely with their own way of properly demultiplexing the raw sequences. Harpy will aim to incorporate demultiplexing these beadtag variants as they become available.

Chromium 10X linked-reads use a format where the barcode is the leading 16 bases of the forward (R1) read. However, haplotagging data does not use that format and many of the tools implemented in Harpy won't work correctly with the 10X format. Once demultiplexed, haplotagging sequences should look like regular FASTQ files of inserts and the barcode is stored in a BX:Z:AxxCxxBxxDxx tag in the read header. Again, do not include the barcode in the sequence.

Like mentioned, the haplotag barcode is expected to be stored in the BX:Z: tag in the read header. This information is retained through the various Harpy steps. An example read header could look like:

@A00814:267:HTMH3DRXX:2:1101:4580:1000  RX:Z:GAAACGACCAACA+CGAACACGTTAGC    QX:Z:F,FFFFFFFFFFF+FF,FFF:FFFFFF   BX:Z:A02C01B11D46

Notably, only the sequence ID (@...) and BX:Z: tag are actually required. In the example above, there are additional tags (RX:Z: and QX:Z:) which arent used by Harpy, but they conform to the SAM comment spec (section 1.5) of TAG:TYPE:VALUE. The takeaway is that the BX:Z: tag can be anywhere in the read header after the sequence ID as long as any tags after it conform to the SAM spec TAG:TYPE:VALUE (see note). Read comments that aren't following the TAG:TYPE:VALUE SAM spec may cause downstream errors.

Reads must be at least 30 base pairs in length for alignment. By default, the qc module removes reads <30bp.

Harpy generally doesn't require the input sequences to be in gzipped/bgzipped format, but it's good practice to compress your reads anyway. Compressed files are expected to end with the extension .gz .

Unfortunately, there are many different ways of naming FASTQ files, which makes it difficult to accomodate every wacky iteration currently in circulation. While Harpy tries its best to be flexible, there are limitations. To that end, for the deumultiplex , qc , and align modules, the most common FASTQ naming styles are supported:

• sample names: a-z 0-9 . _ - case insensitive
  • you can mix and match special characters, but that's bad practice and not recommended
  • examples: Sample.001, Sample_001_year4, Sample-001_population1.year2 <- not recommended
• forward: _F .F _1 .1 _R1_001 .R1_001 _R1 .R1
• reverse: _R .R _2 .2 _R2_001 .R2_001 _R2 .R2
• fastq extension: .fq .fastq case insensitive
• gzipped: supported and recommended
• not gzipped: supported

You can also mix and match different formats and styles within a given directory, although again, this isn't recommended. As a good rule of thumb for any computational work, you should be deliberate and consistent in how you name things.

By the nature of linked read technologies, there will (almost always) be more DNA fragments than unique barcodes for them. As a result, it's common for barcodes to reappear in sequences. Rather than incorrectly assume that all sequences/alignments with the same barcode originated from the same orignal DNA molecule, linked-read aware programs include a threshold parameter to determine a "cutoff" distance between alignments with the same barcode. This parameter can be interpreted as "if a barcode appears more than X base pairs away from the same barcode (on the same contig), then we'll consider them as originating from different molecules." If this threshold is lower, then you are being more strict and indicating that alignments sharing barcodes must be closer together to be considered originating from the same DNA molecule. Conversely, a higher threshold indicates you are being more lax and indicating barcodes can be further away from each other and still be considered originating from the same DNA molecule. A threshold of 50kb-150kb is considered a decent balance, but you should choose larger/smaller values if you have evidence to support them.