Parallelizing Alignment By Splitting Chromosome In Separate Files

Question

[skm770]

The easiest way to do the alignment quickly is to split fasta file for each chromosome and then do the alignment for each chromosome separately. But is this the right way to do so. Are we not bound to get reads which should have mapped to X chromosome but is mapping to Y chromosome?

thanks

[Ashutosh Pandey]

Doing so will surely decrease your search space but it will lead to lot of false positive mapping. For example, a read may have its origin on mitochondria but it may align on chromosome 1 with few mismatches. As Sean Davis said splitting your read file or fastq file and mapping it against the whole genome is a much better option.

[Sean Davis]

Just an aside, splitting the FASTA files by chromosomes could be quite counterproductive with an aligner that scales linearly in the number of reads but is not very sensitive to the size of the genome. If there are 24 chromosomes, for such an aligner, the split by chromosome approach could take quite a bit longer than not splitting.

Answer 1

[Sean Davis]

The more common approach--that avoids the problem you note in your question--is to split the read files (typically FASTQ) into smaller chunks, align, and then merge.

Answer 2

[Pierre Lindenbaum]

You would get some false positive by doing this. I split my results just after bwa using my tool https://github.com/lindenb/jvarkit/wiki/SplitBam

and , as said Sean. If your fastq files are divided into small chunks, you would merge all the chr1_001.bam chr1_002.bam chr1_002.bam chr1_003.bam ... aftter SplitBam

Example:

bwa sampe (...) |\
java -jar dist/splitbam.jar \
    VALIDATION_STRINGENCY=LENIENT  \
    OUT_FILE_PATTERN=TESTSPLITBAM/__CHROM__.bam \
    REF=human_g1k_v37.fasta \
    ADD_MOCK_RECORD=true \
    GENERATE_EMPTY_BAM=true \
    GP=split_g1k_v37_01.txt 


[Fri Jul 26 13:25:56 CEST 2013] Executing as lindenb@master on Linux 2.6.32-358.6.2.el6.x86_64 amd64; OpenJDK 64-Bit Server VM 1.7.0_19-mockbuild_2013_04_17_19_18-b00; Picard version: null
INFO    2013-07-26 13:25:56    SplitBam    reading stdin
INFO    2013-07-26 13:25:56    SplitBam    opening TESTSPLITBAM/CHROMS_01_09.bam
INFO    2013-07-26 13:25:57    SplitBam    opening TESTSPLITBAM/CHROMS_10_0Y.bam
INFO    2013-07-26 13:25:58    SplitBam    opening TESTSPLITBAM/CHROMS_OTHER.bam
INFO    2013-07-26 13:35:58    SplitBam    closing group CHROMS_01_09
INFO    2013-07-26 13:35:59    SplitBam    closing group CHROMS_10_0Y
INFO    2013-07-26 13:35:59    SplitBam    closing group CHROMS_OTHER
INFO    2013-07-26 13:36:00    SplitBam    closing group Unmapped
Runtime.totalMemory()=1916600320

[Sean Davis]

Some variant callers take a "region" parameter, allowing parallelized variant calling on a single BAM file.

[Pierre Lindenbaum]

good point, but an operation like sorting+merging will be faster with one bam per chromosome.

[Biomonika (Noolean)]

Won't split bams vs one huge bam also call variants differently? (based on algorithm chosen, of course)

[Pierre Lindenbaum]

no as long as all your reads are in the same file for the same chromosome.

[Biomonika (Noolean)]

Good point, thanks.