収穫祭で発表しました

少し遅くなりましたが,3/18の収穫祭で発表した時のスライドへのリンクを貼っておきます.

 

Ustreamの録画はこちらにあります.

発表内容は主にgmapとtogofarm botについてです.

gmapの紹介

gmapとは

gmapはTopHatなどのshort read処理ツールをSun Grid Engineで並列分散処理させる際の支援ツールです.gmapを使うことで,各ツールのオプションの設定や出力ディレクトリの作成,Sun Grid Engineへのジョブ投入といった一連の処理がコマンドひとつで簡単に実行できるようになります.TopHat,Bowtie,SOAP2の実行に対応しています.

現在gmapはGitHubで公開中です.以下のURL先から入手することができます.利用にはRuby(1.9.1以降)とSun Grid Engine,およびTopHat,Bowtie,SOAP2などのツールがインストールされているクラスタ環境が必要です.
https://github.com/mickey24/gmap

以降,gmapを使った場合のメリットについて,例を交えながら紹介していきたいと思います.

TopHatをコマンドラインから使う場合

以下の設定でTopHatによる解析を行う場合について考えます.

  • マッピング先のゲノムのBowtieインデックス:/path/to/genome/mouse/chr1 など (染色体番号:1〜19, X, Y)
  • 入力ファイル:/path/to/SRP0123/SRX0123/SRR0123.fastq
  • 出力ディレクトリ:./result/1 など(各染色体ごとに結果を保存)

TopHatをコマンドラインから手入力で実行した場合の例を以下に示します.

$ mkdir result
$ tophat -o result/1 /path/to/genome/mouse/chr1 \
  /path/to/SRP0123/SRX0123/SRR0123.fastq && \
tophat -o result/2 /path/to/genome/mouse/chr2 \
  /path/to/SRP0123/SRX0123/SRR0123.fastq && \
tophat -o result/3 /path/to/genome/mouse/chr3 \
  /path/to/SRP0123/SRX0123/SRR0123.fastq && \
...
tophat -o result/19 /path/to/genome/mouse/chr19 \
  /path/to/SRP0123/SRX0123/SRR0123.fastq && \
tophat -o result/X /path/to/genome/mouse/chrX \
  /path/to/SRP0123/SRX0123/SRR0123.fastq && \
tophat -o result/Y /path/to/genome/mouse/chrY \
  /path/to/SRP0123/SRX0123/SRR0123.fastq

これは流石に面倒ですね.同じようなコマンドを染色体の数(1〜19, X, Yで計21)だけ入力しなければならず,またミスもしやすく危険です.for文を使えば以下のようにある程度短く効率的に書けますが,それでもTopHatを使う度に毎回自分の手でfor文を入力するのは大変です.

$ mkdir result
$ for i in `seq 1 19` X Y
do
  tophat -o result/${i} /path/to/genome/mouse/chr${i} \
    /path/to/SRP0123/SRX0123/SRR0123.fastq
done

シェルスクリプトを使う場合

シェルスクリプトは同じようなコマンドを何度も実行する時に使うと非常に便利です.例えば以下のようなシェルスクリプトを書き,mouse.shなどのファイル名で保存します.

input=$1
output=$2

mkdir ${output}

for i in `seq 1 19` X Y
do
  tophat -o ${output}/${i} /path/to/genome/mouse/chr${i} ${input}
done

これを以下のようにコマンドラインから実行します.

$ sh mouse.sh /path/to/SRP0123/SRX0123/SRR0123.fastq result

これでmouseのゲノムに対するTopHatの処理が随分楽に実行できるようになりました.しかし,この場合でも以下のような問題が残ります.

  1. ゲノムのBowtieインデックスやTopHatのオプションを変えたい時にスクリプトを書き換えなければならない
  2. TopHatを染色体の数だけ逐次実行(上の場合は21回)するのは非常に時間がかかる

1についてはシェルスクリプトのコマンドライン引数でゲノムなどを指定するようにすればある程度解決できますが,今度はスクリプト実行時に毎回Bowtieインデックスのpathのような冗長な引数を入力しなければならなくなるという問題が発生してしまいます.染色体番号の指定も面倒になりそうです.かといってゲノムやオプションごとにスクリプトをコピーして当該箇所だけ書き換えたものを作っていくと,同じようなスクリプトが散在して管理が大変になる怖れがあります.

2については,ひとつのマシンで全染色体に対する処理を行うのではなく,以下のようにクラスタ環境で並列分散処理をすることで解決できます.

Sun Grid Engineを使う場合

Sun Grid Engineはクラスタ環境用のジョブ投入システムです.qsubコマンドを使うことで,シェルスクリプトなどのプログラムをジョブとしてクラスタ環境に投入し,Sun Grid Engineが割り当てたマシンやリソースを使って実行させることができます.

Sun Grid Engineを使った場合のメリットは以下の通りです.

  1. 大量のジョブを複数のマシンに投入し,同時に実行させることができる
  2. ジョブのスケジューリングやリソース割り当てといった問題はSun Grid Engineが解決してくれる

TopHat,Bowtie,SOAP2は,ひとつの入力ファイルに対する染色体ごとの処理は基本的にそれぞれ独立して実行させることができます.そのため,Sun Grid Engineを使って各染色体ごとに1ジョブずつ投入することで同時に実行させることが可能です.十分な計算リソースがあれば,ひとつのマシンで逐次実行する場合と比べて大幅な高速化が可能です.

しかし,Sun Grid Engineを使うことで新たな問題もいくつか出てきます.

  1. 新たにqsubコマンドの引数も適切に指定する必要がある.シェルスクリプトの引数でこれらを指定できるようにした場合,スクリプトのコマンドライン引数の数がさらに増え,スクリプトのコードも複雑化する.
  2. PATHなどの環境変数も気を遣う必要がある
  3. ツールの引数や環境変数が不適切だった場合,投入されたジョブが異常終了することがある.この場合(特に環境変数が原因の場合)エラーの特定が難しい.

TopHatなどのツールを実行する度に,これらのことに気を遣いながらシェルスクリプトを書くのは非常に大変です.また,前節で挙げた問題1もまだ解決していません.そこでgmapの出番です.

gmapを使う場合

gmapを使った場合のコマンドを以下に示します.

$ gmap -t tophat -g mouse -o result \
  /path/to/SRP0123/SRX0123/SRR0123.fastq

これだけで,mouseの各染色体についてTopHatのジョブをSun Grid Engineで同時実行することができます.各ツールの引数の指定,Sun Grid Engineへのジョブ投入,出力ディレクトリの作成といった作業は全部gmapがやってくれます.

gmapを使った場合の利点を以下に示します.

  1. ツールやゲノムの指定が簡単にできる
  2. 設定ファイル(.gmap)を元にgmapがSun Grid Engineや各ツールの引数を指定してくれる
  3. ジョブ投入や出力ディレクトリの作成といった作業はgmapがやってくれる
  4. gmapが設定や与えられた引数が適切かどうかチェックし,ジョブが異常終了することを未然に防いでくれる

gmapを使うには,あらかじめホームディレクトリに.gmapという名前のファイルを設置し,そこに設定を書いておく必要があります..gmapファイルには主に以下の設定を記述します.

  • TopHatなど各ツールのpath
  • genome_config: 各ゲノムのBowtieインデックスのpath,染色体番号
  • project_config: TopHatなどのツールのオプション(SRPごとに指定)

各ゲノムのBowtieインデックスについての設定例を以下に示します.

genome_config:
 mouse:
  genome_path : /path/to/genome/mouse/chr%s
  chrnum      : 1-19,X,Y
 human:
  genome_path : /path/to/genome/human/chr%s
  chrnum      : 1-22,X,Y

このように設定を記述しておくことで,違うゲノム(例: human)を使ってTopHatを処理したい時も簡単に実行できるようになります.

$ gmap -t tophat -g human -o result \
  /path/to/SRP0123/SRX0123/SRR0123.fastq

tophatなどのツールに与える引数も.gmapファイルに書きます.入力ファイルのSRPの番号ごとに同じ引数を使うことが多いため,各ツールの引数はSRPごとに指定できるようになっています.以下に例を示します.

project_config:
 default:
  tophat    : "--solexa-quals -r 200 --mate-std-dev 50"
  bowtie    : "-X 250 -I 150"
  soap2     : "-x 250 -m 150"
 SRP0123:
  tophat    : "--solexa-quals -r 200 --mate-std-dev 50"
  bowtie    : "-X 250 -I 150"
  soap2     : "-x 250 -m 150"

これらの設定を書いておくだけで,入力ファイルに合わせてTopHatなどのツールに適切な引数が与えられるようになります.

以上

gmapでTopHat,Bowtie,SOAP2を使う大規模計算を少しでもサポートできれば幸いです.

 

2010/10/15のDBCLS

クラスタ環境のツールのアップデート作業

DBCLSのSun Grid Engineクラスタ環境に以下のツールの最新版をインストールした.

  • TopHat 1.1.1 (/usr/local/tophat-1.1.1)
  • Cufflinks 0.9.1 (/usr/local/cufflinks-0.9.1)

gmap制作

  • ジョブ投入処理を除きほぼ完成
  • テストを書いてない箇所がいくつかあるので何とかしないと

2010/10/01のDBCLS

gmap制作

  • 最新のTopHat,Bowtieが実行できるように修正
  • 設定ファイルやコマンドライン引数のvalidationを行うコードのテストがほぼ作成
  • 10月中に形にしたい

MacPortsパッケージのアップデート後に特定のパッケージをダウングレードする方法

MacPortsパッケージのアップデートを行うと,最新パッケージのバージョンのせいで既存のシステムが動かなくなったりすることがある.その場合,システムを最新パッケージに合わせて更新・修正したり,他のライブラリを調整したりすれば解決する場合もあるが,現時点では解決策が分からない&どうしてもシステムを以前のように動ける状態にしたい時は,当該パッケージをダウングレードすることで一時的に解決できる.

まずダウングレードしたいパッケージを確認する.port upgradeでパッケージをアップデートした場合は,以下のように過去のバージョンのパッケージも残っている.

$ port installed ruby19
The following ports are currently installed:
  ruby19 @1.9.1-p376_0
  ruby19 @1.9.1-p378_0
  ruby19 @1.9.2-p0_1
  ruby19 @1.9.2-p0_2 (active)

port activateでダウングレードしたいバージョンを指定し,それを有効化する.

$ sudo port activate ruby19 @1.9.1-p378_0
--->  Deactivating ruby19 @1.9.2-p0_2
--->  Activating ruby19 @1.9.1-p378_0

これでダウングレード完了.

$ port installed ruby19
The following ports are currently installed:
  ruby19 @1.9.1-p376_0
  ruby19 @1.9.1-p378_0 (active)
  ruby19 @1.9.2-p0_1
  ruby19 @1.9.2-p0_2

しかし,これはあくまで一時的な解決策なので注意が必要だ.

2010/09/29のDBCLS

クラスタ環境のツールのアップデート作業

DBCLSのSun Grid Engineクラスタ環境に以下のツールの最新版をインストールした.

  • Bowtie 0.12.7 (/usr/local/bowtie-0.12.7)
  • TopHat 1.0.14 (/usr/local/tophat-1.0.14)
  • Cufflinks 0.9.0 (/usr/local/cufflinks-0.9.0)

g86のアップデート作業

月末恒例のアップデート作業.今回は特に問題なく終わった.

g86のアップデート作業手順の記事の作成

g86のサーバ管理を引き継いでくれる人に参考にしてもらうために.

C++コード読み

y_benjo さんのLDAプログラムのC++コードを読んでメモリ使用量を削減したり高速化したりするためのアイディアを出した.std::mapではなくstd::vectorで済ませたり.

Mac Proサーバ「g86」のアップデート作業手順

DBCLSの統合牧場では,牧場の住民が好き勝手に使うMac Proサーバ「g86」が動いています.私はこのサーバのアップデート作業を毎月月末に行っています.

g86のアップデート作業は以下の手順で行っています.

  1. アップデート予告(1週間前)
  2. アップデート作業直前の確認
  3. MacPortsのパッケージのアップデート
  4. Mac OS Xのソフトウェアアップデート

この作業手順についてメモしておきます.

アップデート予告(1週間前)

まず,アップデート作業を行う1週間前に以下の3点をサーバ利用者に予告しておきます.

  • アップデート作業予定日
  • アップデート作業時にサーバの再起動が必要であること
  • MacPortsのアップデートで更新されるパッケージ一覧(都合でアップデートしてほしくないパッケージがある場合は1週間以内に連絡してもらう)

MacPortsのアップデートで更新されるパッケージ一覧はport outdatedで表示することができます.この時にport selfupdateで最新のパッケージ一覧を取得しておきます.

$ sudo port -d selfupdate
$ port outdated

portコマンドの-d(debug)オプションはデバッグ出力を有効にするためのもので,これを指定すると非常に細かいレベルで実行ログが画面に出力されます.

アップデート作業直前の準備

まずg86にログインし,他のユーザがログイン中・作業中でないか確認する必要があります.wコマンドでログイン中のユーザ一覧を,topコマンドで実行中のプロセス一覧を表示して確認します.

$ w
$ top -u

topコマンドに-uを指定すると,CPU使用率が高いプロセスから順に一覧表示することができます.ユーザがログイン中・計算中の場合は計算停止とログアウトをしてもらってから以下の作業を進めます.

MacPortsのパッケージのアップデート

MacPortsの古いパッケージはport upgrade outdatedで一括アップデートができます.

$ sudo port -v upgrade outdated

portに-v(verbose)を指定するとパッケージインストール時のconfigureやmakeなどの作業状況が細かく表示されます.途中でエラーが発生した時の対処の参考になるため,port installやport upgradeを実行する時は-vもセットで指定することをおすすめします.-dを指定するとさらに細かいレベルで作業状況が出力されますが,普段は-vで十分でしょう.

ユーザからアップデートしてほしくないパッケージが指定されている場合は,少し面倒ですが以下のようにします.

$ sudo port -v upgrade `port outdated | tail +2 | awk '{print $1}' | grep -v '^ruby$'`

上の例ではruby以外のoutdatedなパッケージがすべてアップデートされます.grep -vでアップデートしたくないパッケージ名を指定して一覧から除外しています.パッケージ名の前後に^と$を付けているのは,例えばgrep -v rubyのように^$なしで指定するとjrubyもパターンにマッチして意図せずアップデートされないといったことがあるためです.

アップデート作業が終わったらMac OS Xの再起動を行います.再起動はGUIからでもいいですし,以下のようにコマンドラインから行うことも可能です.

$ sudo shutdown -r now

-rで再起動(reboot),nowで今すぐ実行という意味になります.

Mac OS Xのソフトウェアアップデート

基本的にはg86にGUIでログインしてメニューの「リンゴマーク」→「ソフトウェア・アップデート」からアップデート作業を行えばOKです.再起動が必要な場合はそのままGUIから行いましょう.

また,softwareupdateコマンドを使うことで,コマンドラインからソフトウェアアップデートを行うこともできます.

# 利用可能なアップデートの一覧を表示
$ softwareupdate -l
# アップデートを全てインストール
$ sudo softwareupdate -i -a

各オプションはそれぞれ-l(list)で一覧表示,-i(install)でインストール,-a(all)で全てのパッケージを選択という動作になります.

アップデート後に再起動が必要な場合はそのことが表示されますので,shutdownコマンドで再起動します.

$ sudo shutdown -r now

注意点

  • アップデート作業日にport selfupdateしてはいけません.port selfupdateを実行するとアップデートが必要なパッケージの一覧が更新され,1週間前にユーザに予告していたものと変わってしまう可能性があるためです.

コマンドのPATH

この記事で示した重要コマンドのpathを以下に示しておきます.PATHが通っていないせいで各コマンドが見つからなかった場合は参考にしてください.

/opt/local/bin/port
/sbin/shutdown
/usr/sbin/softwareupdate

2010/09/17のDBCLS

gmap制作

  • 出力やエラー処理をもっとユーザフレンドリーな感じにしたい
  • ジョブをqsubでsubmit後にエラーで止まっているというようなことを減らしたい
  • どこからテストを書けばいいのか迷ったりしてなかなか進まない…
  • ある程度割り切って作業を進めた方がいいのかも

2010/09/10のDBCLS

これから作業していきたいこと

もうそんなに時間が残ってないので着実に進めたい

  • gmapの改良,公開,引継ぎ
  • body3dのソースの改良,引継ぎ
  • togofarm botのソースの改良,引継ぎ
  • nearest_geneなどの細々としたスクリプトの改良,整理,引継ぎ.

gmapの改良

  • テストを書いたりリファクタリングしたり.

発現データの比較処理用のプログラムの作成 (nearest_gene)

  • gtfファイルを入力として与えられるようにした.
  • reference.gtf vs その他のgene_expression_domain.exprの比較を行うバージョンのプログラム(nearest_gene_r)を作った.

2010/09/03のDBCLS

PNEのエラーの対処(未完)

  • g86サーバのRubyのバージョンを1.9.2に上げたら昨年度にsyou6162が作ったPNEが動かなくなった.
  • require “iconv”に失敗する.irbでも確認したけどダメだった.
  • find /opt/local/lib/ruby1.9 -name \*iconv\*を実行したところiconvが見つからなかった.標準ライブラリなのに….
  • 1.9.1のiconv.bundleをコピーして設置したらrequire “iconv”はパスしたものの,今度はSinatraでエラー(ArgumentError).1.9.2に対応していないのだろうか….
  • とりあえずRubyを1.9.1にダウングレードして対処した.
  • 「サーバのソフトウェアをアップデート→既存のサービスが動かなくなる」という問題はサービスのメンテナがいなくなると対処が困難だし非常に頭が痛い.
    • GCC,Boost,Rubyなどの一部のパッケージだけ「ひたすら最新版にアップデートする」以外のポリシーでアップデートしていくようにした方がいいのかもしれない.しかしセキュリティの都合上いつかはアップデートしなければならない.うーむ….

gmapのコードの修正

  • 最終的にGitHubで公開できる形に持っていきたい.

発現データの比較処理用プログラム (nearest_gene)

  • iNutと話し合い,後の解析で利用しやすくなるように修正を加えた.
  • 各発現データファイルinput1, input2, …の各遺伝子発現領域について,他の発現データファイルごとに最も近い発現領域を探し,ファイルに出力するようにした.
  • ついでにGistにアップロードした