<p>I would suggest looking at sample metadata:</p>
<blockquote>
<p>Library:</p>
</blockquote>
<blockquote>
<p>Name: TruSeq RNA</p>
</blockquote>
<blockquote>
<p>Instrument: Illumina HiSeq 2000</p>
</blockquote>
<blockquote>
<p>Strategy: RNA-Seq</p>
</blockquote>
<blockquote>
<p>Source: TRANSCRIPTOMIC</p>
</blockquote>
<blockquote>
<p>Selection: PolyA</p>
</blockquote>
<blockquote>
<p>Layout: PAIRED</p>
</blockquote>
<p>You can see that it's paired. You can look at the spot descriptor at the page you link to see more information about the design.</p>
<p>There is no multiplexing information available there. I would instead look at the <a href="https://www.ncbi.nlm.nih.gov/sra?term=SRP074191" rel="nofollow noreferrer">overall project and its metadata</a> to find the different replicates. It looks like there are 2 samples x 3 replicates each, deposited independently. So it is likely to already be demultiplexed, and you can just download them individually.</p>
<p>&quot;Unstranded&quot; isn't really a meaningful term for this, if I understand correctly. Forward and reverse read pairs don't correspond to forward and reverse on the chromosome, but to the way that sequencing-by-synthesis happens on the machine. So the mapping orientation is not really relevant.</p>
<p>I infer that you are working from a single FASTQ file. If you are working from a single FASTQ file for paired-end out of SRA, then the FASTQ file is not yet resolved into F+R reads. I would suggest rerunning the FASTQ conversion with <code>--split-3</code> or similar option.</p>

CC BY-SA 4.0
2021-03-24T21:02:46.657Z
Thanks! The term 'unstranded' was determined by RSeQC infer_experiment.py. The reads were 47% forward, and 47% reversely mapped. So the resulting counts from the single FASTQ file worked even w/o the FASTQ conversion. The experiments from the entire project are all 6 independent (6 x 1 sample), not 2 x 3 samples. I worry that the reported replicates are actually missing in the uploads and was hoping to confirm this from the FASTQ files somehow.
Geo Vogler
CC BY-SA 4.0
2021-03-25T03:17:25.430Z
@GeoVogler That is helpful background for trying to answer the question. Where do you see the 6 x 1 info? I was not able to track down the actual study that originated these samples, linking that would be helpful. All I am seeing is the 3 samples x 2 treatments on SRA.
Maximilian Press
CC BY-SA 4.0
2021-03-25T03:27:40.317Z
The three samples are from three individuals (mother/father/proband), not a single one (see Biosamples). The layout of SRA with Project/BioSamples/Reads could really be improved. If there is no indication of replicates I will need to contact the lab directly, I just thought maybe there is an easy way to gauge the presence of Index sequences inside a FASTQ file.
Geo Vogler
CC BY-SA 4.0
2021-03-25T13:21:05.503Z
@GeoVogler the index reads were probably split out in initial processing, but they are often preserved in FASTQ headers by e.g. `bcl2fastq`. SRA unfortunately has a tendency to strip out useful information from the FASTQ header, which does sometimes include the index sequence for each read. The authors should have the original files in theory, yes.
Maximilian Press
CC BY-SA 4.0
2021-03-24T20:43:28.097Z
2021-03-24T20:43:28.097Z
Maximilian Press
<p>I am trying to understand how data that was uploaded to SRA (<a href="https://www.ncbi.nlm.nih.gov/sra?LinkName=biosample_sra&amp;from_uid=4510743" rel="nofollow noreferrer">https://www.ncbi.nlm.nih.gov/sra?LinkName=biosample_sra&amp;from_uid=4510743</a>) can be analyzed with the assumption that the FASTQ file should contain replicate information (3 replicates within the sample). I downloaded the file and ran it with Nextflow, and it was mapped to the human genome and determined to contain unstranded reads of 50bp, both directions.</p>
<p>Which steps can I take to infer if the FASTQ file indeed is not demultiplexed?</p>
<p>Many thanks,
Geo</p>
<p>The header of the FASTQ looks like this:</p>
<pre><code>@SRR3467208.1 1/1
NTCTCTATGTCCACTCTGGAGCCTTTAAGTGCCACTTGAGGGCCTTTAAC
+
#4:D;DDEHHFHHIJJIJJGHGHJJI@HFIIJJHJJIG?9CFHIIIHHHG
@SRR3467208.2 2/1
NGTGCTGTGTGTGCATGTGTGTGCGTGTGTGTGCTGTGCGTTTGTGTGTG
+
#1:B:BDDFFFFFFFBGFHIFIIFGFFGFGFGIIIIIIEFGGIIFFIFII
@SRR3467208.3 3/1
NGTCACTTGGCATCTGGCCATCGGGCTGGATGCCGTGTTCCAGGCAGTAG
+
#1:A=DDDB&lt;&lt;CFAFGI@FGG9A@68CEG;DB?&lt;DGGGE49?BBF2B=FF
@SRR3467208.4 4/1
NTCCGGGGCTCCAGCAACCAGAAGAGGGAAAAGCTGTCTTCGGTGATGTC
+
</code></pre>

<rna-seq><fastq><demultiplexing>
Demultiplexing FASTQ file without index information
# Demultiplexing FASTQ file without index information

(Asked by: username_0 on 2021-03-24)

I am trying to understand how data that was uploaded to SRA (https://www.ncbi.nlm.nih.gov/sra?LinkName=biosample_sra&from_uid=4510743) can be analyzed with the assumption that the FASTQ file should contain replicate information (3 replicates within the sample). I downloaded the file and ran it with Nextflow, and it was mapped to the human genome and determined to contain unstranded reads of 50bp, both directions.
Which steps can I take to infer if the FASTQ file indeed is not demultiplexed?
Many thanks,
Geo
The header of the FASTQ looks like this:
@SRR3467208.1 1/1
NTCTCTATGTCCACTCTGGAGCCTTTAAGTGCCACTTGAGGGCCTTTAAC
+
#4:D;DDEHHFHHIJJIJJGHGHJJI@HFIIJJHJJIG?9CFHIIIHHHG
@SRR3467208.2 2/1
NGTGCTGTGTGTGCATGTGTGTGCGTGTGTGTGCTGTGCGTTTGTGTGTG
+
#1:B:BDDFFFFFFFBGFHIFIIFGFFGFGFGIIIIIIEFGGIIFFIFII
@SRR3467208.3 3/1
NGTCACTTGGCATCTGGCCATCGGGCTGGATGCCGTGTTCCAGGCAGTAG
+
#1:A=DDDB<

**Tags:** rna-seq, fastq, demultiplexing

---

## 1 answers

### Answer by username_1 on 2021-03-24. Score: 1 | Accepted answer

I would suggest looking at sample metadata:

> Library:

> Name: TruSeq RNA

> Instrument: Illumina HiSeq 2000

> Strategy: RNA-Seq

> Source: TRANSCRIPTOMIC

> Selection: PolyA

> Layout: PAIRED

You can see that it's paired. You can look at the spot descriptor at the page you link to see more information about the design.

There is no multiplexing information available there. I would instead look at the [overall project and its metadata](https://www.ncbi.nlm.nih.gov/sra?term=SRP074191) to find the different replicates. It looks like there are 2 samples x 3 replicates each, deposited independently. So it is likely to already be demultiplexed, and you can just download them individually.

"Unstranded" isn't really a meaningful term for this, if I understand correctly. Forward and reverse read pairs don't correspond to forward and reverse on the chromosome, but to the way that sequencing-by-synthesis happens on the machine. So the mapping orientation is not really relevant.

I infer that you are working from a single FASTQ file. If you are working from a single FASTQ file for paired-end out of SRA, then the FASTQ file is not yet resolved into F+R reads. I would suggest rerunning the FASTQ conversion with `--split-3` or similar option.

> **Comments:**
> **username_0**: Thanks! The term 'unstranded' was determined by RSeQC infer_experiment.py. The reads were 47% forward, and 47% reversely mapped. So the resulting counts from the single FASTQ file worked even w/o the FASTQ conversion. The experiments from the entire project are all 6 independent (6 x 1 sample), not 2 x 3 samples. I worry that the reported replicates are actually missing in the uploads and was hoping to confirm this from the FASTQ files somehow.  
> **username_1**: @GeoVogler That is helpful background for trying to answer the question. Where do you see the 6 x 1 info? I was not able to track down the actual study that originated these samples, linking that would be helpful. All I am seeing is the 3 samples x 2 treatments on SRA.  
> **username_0**: The three samples are from three individuals (mother/father/proband), not a single one (see Biosamples). The layout of SRA with Project/BioSamples/Reads could really be improved. If there is no indication of replicates I will need to contact the lab directly, I just thought maybe there is an easy way to gauge the presence of Index sequences inside a FASTQ file.  
> **username_1**: @GeoVogler the index reads were probably split out in initial processing, but they are often preserved in FASTQ headers by e.g. `bcl2fastq`. SRA unfortunately has a tendency to strip out useful information from the FASTQ header, which does sometimes include the index sequence for each read. The authors should have the original files in theory, yes.  

---

