5
$\begingroup$

In the methods of this paper, the authors say:

To simplify analysis, we first removed any dephased reads in our library (last 6 bases of read did not match the expected sequence).

I have read this post and this one, and I think that a dephased read is one (according to the first paper) where the last 6 bases are not detected with good quality. In particular, I think this may be an example of a dephased read:

@...
CACACACACCAGTAAAAAANAGTTGCNNCNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
+
AAAAAEEAEEEEEEEEEE6#EAEEEE##E#####################################

where the quality of the read drops in the middle. Is that correct? If yes, should they be all of bad quality or at least one? And, if not, how can I detect a dephased read?

$\endgroup$
4
$\begingroup$

Phasing in Illumina data means that the read you get is shifted one base before or after what the sequence really should be. They must be expecting some constant 6 bases at the end of each read, and they are throwing out all reads that don't have those 6 bases. This would include N's, but a small deletion or insertion would also cause the last 6 bases to not match. This is in theory detectable and fixable; the dropSeq protocol for instance catches instances where improperly short cell barcodes shift the UMIs, but these authors look like they decided not to try and bother, and just throw out everything that didn't match their exact expectations.

$\endgroup$
1
  • $\begingroup$ Interesting, thanks. Is the dephased read considered only in the reverse read (R2), where barcodes and UMI are sequenced? I assume that during the mapping of the forward read the aligner is able to deal with dephased reads - while during barcode extraction dephased reads may introduce issues, if I understood correctly your answer. $\endgroup$
    – gc5
    Sep 27 '18 at 23:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.