ソフトウェア結果比較【BAMソート編・1】のつづきです。
前回、同じBAMをsamtools sortとSortSam.jar(picard)でソートしたところ、結果のBAMが異なりました。
異なる箇所を調べるため、まず結果BAMをsamtools view -hでSAMに変換しました。
【samtools sortでソート】
・結果（SAMに変換）
sort_samt.sam（666,626 bytes）
【SortSam.jarでソート】
・結果（SAMに変換）
sort_pica.sam（666,651 bytes）
これらのSAMをdiffコマンドで比較したところ、2点違いがありました。
違い1：ヘッダー
SortSam.jarでソートしたBAMには、1行目に
@HD VN:1.0 SO:coordinate
という行がありましたが、samtools sortでソートしたBAMにはありませんでした。
@HDタグは、SAMの仕様によると「ヘッダー行の先頭につけるもの」とあります。
BWAやsamtoolsはデフォルトでは@HDタグをつけませんが、picardを使うと自動的に@HDタグがつくようです。
違い2：同一ポジションにおける並び順
同じポジションに複数のリードがマッピングされている場合、それらのリードの順番が異なる場合がありました。
一例を挙げます。
今回のデータでは、
chr8 75275246
にSRR077861.62とSRR077861.104の2リードがマッピングされていて、sort_samt.samではこれらの並びが
SRR077861.62
SRR077861.104
の順になっていましたが、sort_pica.samでは逆になっていました。
他にこのようなところが2か所ありました。
今回のデータに関しては、これ以外の違いはありませんでした。
この程度の違いなら、どちらを使っても問題なさそうです。
その他
今回のBAMのソートのようにメモリを大量に使う処理は、デフォルトで/tmpに中間ファイルを大量に出力する場合が多いようです。
サイズの大きいBAM（46GB）でもソートを試してみたところ、SortSam.jarの場合は「-Djava.io.tmpdir=mytmpdir」をつけて中間ファイル出力先を変更しないとメモリ不足で落ちましたが、samtools sortだとデフォルトでも実行できました。
テストデータやその時のマシンの使用状況にもよると思いますが、samtools sortのほうがもしかすると若干「大きいファイルに強い」のかもしれません。
今後、他の処理についてもソフトウェアによる違いを検証してみたいと思います。
