<p>For ChIP-seq it shouldn't really matter. But do be aware that by default, <code>samtools merge</code> retains read group information (the <code>@RG</code> field in the header) from each input file. This could pose a problem for some downstream analyses (e.g. for the GATK HaplotypeCaller) if you want the merged data to be considered as all part of the same sample. You can change this behaviour using the <code>-c</code> option. </p>

CC BY-SA 3.0
2017-06-06T14:12:19.590Z
I do not think one need `@RG` information for a ChIP-Seq , I mean it is very unlikely that someone would like to do a variants calling with ChIP-Seq. So in any case it it would hardly matter. I would just not mention about the `@RG` here since people might get confused.
ivivek_ngs
CC BY-SA 3.0
2017-06-06T20:19:12.490Z
Fair point. But since olga did ask about advantages or disadvantages, I thought it would be worth mentioning. It might be useful in the future, or for other users, when merging files for other applications besides ChIP-seq, since `samtools merge` is widely used.
Sarah Carl
CC BY-SA 3.0
2017-06-06T08:19:37.980Z
2017-06-06T08:19:37.980Z
Sarah Carl
<p>Agree with the others that it doesn't really matter. One thing to note though - if you're deduplicating your BAM files (you probably should for ChIP-seq data), make sure that you do this <em>after</em> merging.. :)</p>

CC BY-SA 3.0
2017-06-06T18:02:08.287Z
Note that if instead of one library, you have multiple technical replicates (ie multiple libraries from the same sample), you should do aligning for each technical replicate separate, then deduplicate, and THEN merge. This allows you to keep unique fragments from each library that might look like PCR duplicates (because they map to the same place) but are actually unique.
Daniel Kim
CC BY-SA 3.0
2017-06-06T17:40:13.550Z
2017-06-06T17:40:13.550Z
ewels
<p>I don’t think it matters. Both are easy to merge (BAM via <code>samtools merge</code>, and (gzipped) FASTQ via <code>cat</code>), and neither method has specific disadvantages, unless your FASTQ files are sorted for some reason (but they generally shouldn’t be).</p>

<p>One advantage of keeping the FASTQ files separate is that it makes it slightly easier to parallelise the mapping step: just run the mapper in parallel on the separate FASTQ files. Although <code>bowtie</code> has an option (<code>-p</code>) for this, throughput from that is slightly worse than running the mapping on split files.</p>

CC BY-SA 3.0
2017-06-03T12:48:05.047Z
2017-06-03T12:48:05.047Z
Konrad Rudolph
<p>I need to merge sequencing data from different sequencing runs but for the same ChiP-seq library (HiSeq 2000).</p>

<p>Are there any potential advantages or disadvantages when merging files at .fastq or .BAM stage (alignment with Bowite/1.1.2)?</p>

<chip-seq>
Merging sequencing data for ChIP-seq experiments
# Merging sequencing data for ChIP-seq experiments

(Asked by: username_0 on 2017-06-03)

I need to merge sequencing data from different sequencing runs but for the same ChiP-seq library (HiSeq 2000).

Are there any potential advantages or disadvantages when merging files at .fastq or .BAM stage (alignment with Bowite/1.1.2)?

**Tags:** chip-seq

---

## 3 answers

### Answer by username_5 on 2017-06-03. Score: 7 | Accepted answer

I don’t think it matters. Both are easy to merge (BAM via `samtools merge`, and (gzipped) FASTQ via `cat`), and neither method has specific disadvantages, unless your FASTQ files are sorted for some reason (but they generally shouldn’t be).

One advantage of keeping the FASTQ files separate is that it makes it slightly easier to parallelise the mapping step: just run the mapper in parallel on the separate FASTQ files. Although `bowtie` has an option (`-p`) for this, throughput from that is slightly worse than running the mapping on split files.


---

### Answer by username_1 on 2017-06-06. Score: 3

For ChIP-seq it shouldn't really matter. But do be aware that by default, `samtools merge` retains read group information (the `@RG` field in the header) from each input file. This could pose a problem for some downstream analyses (e.g. for the GATK HaplotypeCaller) if you want the merged data to be considered as all part of the same sample. You can change this behaviour using the `-c` option.

> **Comments:**
> **username_2**: I do not think one need `@RG` information for a ChIP-Seq , I mean it is very unlikely that someone would like to do a variants calling with ChIP-Seq. So in any case it it would hardly matter. I would just not mention about the `@RG` here since people might get confused.  
> **username_1**: Fair point. But since olga did ask about advantages or disadvantages, I thought it would be worth mentioning. It might be useful in the future, or for other users, when merging files for other applications besides ChIP-seq, since `samtools merge` is widely used.  

---

### Answer by username_3 on 2017-06-06. Score: 2

Agree with the others that it doesn't really matter. One thing to note though - if you're deduplicating your BAM files (you probably should for ChIP-seq data), make sure that you do this *after* merging.. :)

> **Comments:**
> **username_4**: Note that if instead of one library, you have multiple technical replicates (ie multiple libraries from the same sample), you should do aligning for each technical replicate separate, then deduplicate, and THEN merge. This allows you to keep unique fragments from each library that might look like PCR duplicates (because they map to the same place) but are actually unique.  

---

