text: user375: 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)?
  
  user224: 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.. :)
  
  user182: 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. 
  
  user29: 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.
  
original_text: 375: <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>
   224: <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>
   182: <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>
   29: <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>
  