<p>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.</p>

CC BY-SA 4.0
2018-09-27T23:12:09.383Z
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.
gc5
CC BY-SA 4.0
2018-09-27T20:33:27.177Z
2018-09-27T20:33:27.177Z
swbarnes2
<p>In the methods of <a href="http://science.sciencemag.org/content/360/6385/176" rel="nofollow noreferrer">this paper</a>, the authors say:</p>

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

<p>I have read <a href="http://seqanswers.com/forums/showthread.php?t=11553" rel="nofollow noreferrer">this post</a> and <a href="https://www.france-bioinformatique.fr/sites/default/files/EBA/V3-2014/Claude_Thermes_Intro_NGS_EBA-2014-10_v2.pdf" rel="nofollow noreferrer">this one</a>, 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:</p>

<pre><code>@...
CACACACACCAGTAAAAAANAGTTGCNNCNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
+
AAAAAEEAEEEEEEEEEE6#EAEEEE##E#####################################
</code></pre>

<p>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?</p>

<scrnaseq><reads><splitseq>
What is and how to detect a dephased read
# What is and how to detect a dephased read

(Asked by: username_0 on 2018-09-26)

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?

**Tags:** scrnaseq, reads, splitseq

---

## 1 answers

### Answer by username_1 on 2018-09-27. Score: 4

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.

> **Comments:**
> **username_0**: 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.  

---

