リード長とインサート長の関係

先週の「現場の会」で私の喋りの後の質問の中で、ひとつ、深く考えさせられるものがありました。
「リード長を伸ばすために常に酵素を開発しているということだが、酵素をより良いものに変えるのと、インサートの長さと、どちらがクリティカルな問題なのか？」

つまり、酵素を良くすれば長いリードが読める。90分どころか120分、240分レーザー当てても死なないで塩基を読める酵素も出てくるかもしれない。
しかし、一方で、インサートの長さを今の10kbから20kb、30kbと伸ばしていって、これがちゃんと読めるようになるのか？
このせまい小さなZMWの穴に入ることができるのか？

化学的な条件と、物理的な条件と、どちらがよりクリティカルなのか？　ということですね。

今のC2ケミストリーでは、10kbまでのインサートを読むことができて、90分Movieで読んだとき、リード長は平均3.5kb、95パーセンタイルでは8kb、最長は15kbくらい、ロングリードでの精度は約85%です。

-----------------ここから先は仮定の話を前提にしていますので注意！--------------------

これが将来、もし、30kbまで読めるようになったとしましょう。　
でも、30kbまで読める、ということと、30kbのインサートが読める、ということは別ですね。
10kbのインサートを1周半（sense + antisense + sense）読めば30kbですから、30kb読める、ということにウソは無いですね。うん、正しい。
でもちゃんと説明しないと、普通、「すごい！それって30kbのインサートが読めるってことでしょ？」って誤解するでしょうね。　うんうん。
（そのときもっと長いインサートも読めたら最高ですが）

で、30kbのインサートを読めるか？ってことになると、今度は物理的な問題ですね。　ZMWの穴の中に効率的に入らなければいけませんから。
短いインサートの方がZMWに入りやすいってことは知られていますので、マグネットビーズでロングの（今は10kbですが）ライブラリーを効率的にZMWに誘導する方法は、開発されています。　学会のポスターでも発表されていますのでご存じの方もいるでしょう。



・・・・・　と、ここまでぎりぎり公開OKな話でした。

リード長が伸びたとしても、それは読める範囲（インサート長）が伸びた、ということとイコールではないので、誰かに説明するときはこれから注意します。
初めて聞いたひとは絶対誤解すると思いますから。

このブログを読んだあなたは、もう間違えませんよね。




これは私が「現場の会」で喋った、という証拠写真（現場の会・アルバムより拝借）

PacBio RS に付属するソフトの概要

この間「NGS現場の会」で、参加者のひとたちと話していて、気づきました。
PacBio RS に付属するソフトウェア、について今までブログで全然触れていなかった、と。

"PacBio RS Software and Data Analysis" という、最近出来立てのチラシがあるんですが、その中にこんな絵があります。

中央下のシーケンサーから時計回りに、

• RS Remote
• RS Touch
• SMRT Portal
• SMRT View
• DevNet

とあります。このうちDevNetはPacBioのサイトで、開発中のツールなどを提供しているもので、今日は含めません。

では、順番に説明します。

1. RS Remote：　ユーザの用意したWindows PC にインストールします。　ここでランの設定や、実行中のランの様子を確認します。　終わったランの、時間軸でのジョブの様子を見ることもできます（例えば何時に何番目のセルのランが行われていたか、など）
2. RS Touch：　シーケンサー本体にインストールされていて、タッチパネルから操作します。　主に、RS Remoteで設定し保存されたランを、実行する時に使います。　実行中のランの様子をここからも確認できます。　装置のエラー（温度やレーザーの異常、データの転送エラー）などがあれば、この画面に表示されます。
3. SMRT Portal:　ユーザが2次解析を行うときのウェブブラウザアプリです。　ユーザは、用意したLinuxサーバに、SMRT Analysis という2次解析ソフトをインストールします。　SMRT Portalは、このSMRT AnalysisソフトのGUIで、Internet Explore, Fire Fox, Google Chrome のブラウザに対応しています。　SMRT Analysisについては後ほど。
4. SMRT View：　いわゆるゲノムブラウザです。　Java で動き、Mapping の結果などを参照できます。

これらのソフトは似たような名前なので、最初は良くごっちゃになりました。　

特に、RS RemoteとRS Touchは機能が似ている上、名前も似ている。

そしてこれはデータの流れをまとめた図。 

ランの設定をするのがRS Remote（左下）

シーケンサー本体のRS Touch上でランを実行したら1次解析のデータ（ベースコール結果）が作られます。　この1次解析自体は、シーケンサー横の黒いベースコールサーバ（Blade Center）内で行われます。

1次解析データは、HDF5という階層型のデータフォーマットと、生のFastq、Fastaデータが含まれ、これらは自動的にユーザのストレージサーバに転送されます。　

次に、WebアプリであるSMRT Portal（中央下）から、ユーザは、SMRT Analysisにアクセスします。

SMRT Portal上で、ユーザは、ストレージサーバに転送された1次解析データをクエリに、2次解析（MappingとかAssemblyとか）の設定をします。

SMRT Analysisはストレージ内の1次解析データを呼び出し、計算をして、BAMやSAMなどの結果を指定した場所に書き込みます。

ちなみに2次解析のコマンド群をSMRT Pipeと呼んだりします。　

GUIで行いたい方向けに、SMRT Portalがあるんですが、CUIがいい！ってひとはこのSMRT Analysisをコマンドべースで使うのももちろんOK

SMRT Analysisの解析メニューは、

1. BLASR（ブレイザーと発音）というPacのロングリードに向いたアライメントツール
2. GATKのGenotyperを使用したSNP検出ツール
3. ALLORA（アローラと発音）という名のアセンブラー
4. ギャップフィルタリングやScaffoldingをするAHA（アハッ）
5. そしてMethylation 検出

の5つが柱。　5のMethylation検出は今度のバージョン1.3.1から新たに加わります。　

これらについては、そのうち、例を出しながら書く予定。

さて、SMRT Analysisはユーザがサーバにインストールするわけですが、どんなサーバを用意すれば良いのでしょうか？

OSはUbuntu 10.0.4以降、CentOS 5.6以降

MySQL、bash shell、Perl v5.8.8以降、Perl XML parserがインストールされていることが必要です。

ハードウェアの最低条件

ヘッドノード：　16GB～32GBのメモリ、250GBのスペース

子ノード（5つ）：　コアあたり2GBメモリで、ノードあたり8コア、250GBのスペース

ストレージ：　約10TB

これに満たなくても動くことは動きます。

ただ、遅いかも。

メモリは多いに越したことはないけれど、ストレージのディスクを速いのにしたほうが、実行速度は高まるらしいです。　

私は、感覚的にはそうかなあ、って感じですが。

ということで、ユーザがインストールしなくてはならないのはRS RemoteとSMRT Analysisの2つ。

RS Remoteは普通のWindows PCで動くで問題無いが、SMRT AnalysisはそこそこなスペックのLinuxサーバが必要。

特に、大きなゲノムサイズに挑戦するには、メモリは多い方が良いです。

現場の会

先週、「NGS現場の会・第二回研究会 in 阪急エキスポパーク」に行っていました。
私はその前日チュートリアル、というところで1時間時間を頂き、喋ってきました。
PacBioについて、その原理と特徴、PacBioを使ったアプリケーション例などなど。

プレゼンの前の日は大阪入りして、ホテルで夜3時までスライド作って練習していました。
当日は、最初は緊張してレーザーポインタが震え・・・

私の前はRoche、Illumina、LifeTechと続き、そしてPacBio
それぞれのシーケンステクノロジーの特徴が一日でわかる！って感じですばらしい。

終わってみて、話したいことは大体伝わったかな、という感じはします。

あと、 ブログを知っているひとはかなりいました。　最初、みんなに質問したのですが、300名弱ほどオーディエンスがいたそうですが、3分の1くらい手を上げてくれました。

こんなにマニアックなトピックなんですが。

うれしいことです！

いろんな参加者と話ができて、夜はお酒も入って、ゆるーい感じの学会？です。

ゲノム、メタゲノム、リシーケンス、計算技術、IT、メーカー・・・などなど、その筋の方々、特に現場の方々がそろってわいわいやる。

こういうの良いですね。

この業界は意外と横のつながり、というかメーカーや企業の壁を越えての知り合いは多いのです。

競合の会社でも、社員（現場）のレベルでは飲みに行ったりとか。

でも、これだけたくさんの研究者が一同に集まると、もっともっと輪が広がり、新しい出会いがありました。

前のブログ「ショートリードの憂鬱」を知っているひとから声をかけられ、一気に50人くらい新しい知り合いが増えました。

現場の会に感謝です！　

P.S.

私のプレゼンだけ、白黒コピーでした。　他の企業はカラーできれいだったのに。

これには理由があるんです。

23日の午前2時からKinko'sのサイトがメンテナンスになり、ウェブから印刷を注文できなくなったので、3時に書き上げた私は焦り、とりあえず4時前に寝て、朝8時ごろ北梅田のKinko'sまで20分かけて歩き、印刷を注文したんです。

白黒プリンターは2台あるので印刷が速いと言われたので、時間に追われて白黒印刷にしたわけです。

しばらくブログ更新をしていませんでしたが、これから行きますよ！

シンプソンズとPacBioの深い関係

アメリカでは結構人気のあるシンプソンズ。
コメディとしてはちょっと過激、というイメージ。
日本では、知らないひとが多いでしょうね。　私もPacBio にたずさわるまでほとんど知りませんでした。

何でPacBioとシンプソンズが関係あるかって？

それは、PacBioのシーケンサーを操作するプログラムの名前が、全部シンプソンズの登場人物名になっているからなんです!!

例えば、シンプソンズ一家の、ホーマー（父）、マギー（赤ちゃん）、バート（男の子）は、Pacエンジニアが頻繁に使う、あるいは良く耳にするプログラムの名前です。
シーケンサーを前に私たちがそんな言葉を発していても、「何言ってんだ？」と思わないで下さい。
ちゃんと仕事をしているので。

ロボットを操作したり、ベースコールサーバーにアクセスしたりと、ユーザが触ることはないプログラムの名前です。
でも、操作するプログラムの名前が「波平」、「カツオ」、とかだったらすごく恰好悪いのに、アメリカ人にはそういう感覚無いのかなあ。
それともシンプソンズがよっぽど親しみがあるアニメなのだろうか。

ちなみに、ユーザが触る2次解析サーバでも、少し登場します。　
インストールディレクトリのことを、SEYMOUR_HOME　と呼び、このSEYMOURはシンプソンズでは市長のこと。
自動で2次解析が始まるデーモンをKodosと呼び、これはエイリアンの名前。

最初、これらのキャラクター名の意味が分からず、Pacに聞いてました。
相手は、私がシンプソンズを知らないとは知らず、しばらーく無駄な会話のやりとりを続けたのでした。

今日は軽い話でした。




-------------------------------　おまけ　-------------------------------------

ところで、シンプソン一家が住んでいる街の名前は、Springfield です。
この名前も、Pacのあるものの名前なんです。
ここでクエスチョン！
その「あるもの」とは、何でしょう？

Pacの一次解析 その２

パルスデータまでできたら、次はベースデータです。
どうやってパルスからベースコールを出しているのか？

これは、「観測されたパルスがOの時に、そのテンプレート配列がTである確率が、最も高い、Tを、そのテンプレート配列の塩基とする」　ということにしています。
回りくどい言い方ですみません。　数学が得意な方はこちら

あ～あ、そういうことね。　ってわかった方はすごい！
つまり、パルスがこれくらいだったらこれはAである確率が一番高い、とかTである確率が一番高い、とかそういうパターンアルゴリズムがあって、それに当てはめているのです。

そこんとこもっと詳しく！　って思った方、しかしながら、トレースファイルからパルスデータ、その後の一連のベースコールアルゴリズムは、公開されていません。
ですので概念としてしかお伝えできません。　あしからず・・・



さて、PacBioのデータの特徴、エラーの特徴にはどんなものがあるのか。
トレース、パルスデータにヒントがあります。

以前、PacのデータはInsertionエラーがある、と書きましたが、それを含め、Pacのエラーはどんなときに起こるのか？

エンジニアに聞けばまた別の答え（カメラやレーザーだとか、窒素濃度だとか）があるのですが、分子生物学の立場からだと、その答えはポリメラーゼにあります。
（レーザーによるエラーはまた別の特徴があり、窒素濃度によるエラーもまた別の特徴があるので、InDelエラーはほぼポリメラーゼによる、と考えて良いでしょう）
DNAポリメラーゼは、人工的に変異を施しています。　
合成スピードをカメラの技術に合わせて、ダウンさせています。
CellのZMWの底にBiotinでくっつくようにしています。
さらに試薬のpHに耐えられるようにしています。
また、酸素は有害です。
そして何より、自身が蛍光を放つたびに、光子が出すエネルギーに絶えずさらされています。　これによるダメージも大きいのです。

以上の環境下では、ポリメラーゼ君は時に疲れて休んでしまうこともあるでしょう。
ちょっと休んでまた働くこともあれば、そのまま動かなくなってしまうことも。
されにサボって、合成しないときも。

1. サボってDNAを合成しないで、そのまま次に進んでしまうと　・・・・　その塩基ではパルスは検出されないので見かけ上Deletionになります。
2. 合成はしても、疲れて休んで動かないと、蛍光を外さないので2個＋分読まれてしまうことも　・・・　その塩基では2個分読まれてしまい、見かけ上のInsertion
3. さらに2個分の蛍光が、テンプレートと同じときと違うとき(間違いパルス)の2種類あるのでInsertionにも2種類あるのです。
4. 合成はしたけど間違ったパルスが検出された　・・・　これはMiscall

というわけで、ポリメラーゼの働きがInDelエラーに大きく影響を与えるのです。
もちろん、同じ蛍光が2つ並んだ時が、ポリメラーゼ君のお休みによるものなのか、真にホモポリマーによるものなのか、その見分けは、簡単ではありません。
モデル式を用意して、当てはめて、区別しているのです。
単純に偶数倍のパルスの幅があるからそれで割る、みたいなことよりもずっと賢い計算をしているそうです。

Pacの一次解析 その１

今日はPacの一次解析について書きます。
NGSではおなじみですが、ご存じない方のためにちょっと説明すると、一次解析、二次解析、三次解析というのあって、それぞれ、

1. 一次解析：　シーケンサーから出てきた生データから、塩基配列を求める（ベースコールする）
2. 二次解析：　塩基配列になったリードデータを、アセンブルまたはリファレンスにマッピングする
3. 三次解析：　マッピングされたデータをもとに、Contigをつなげたり、配列から何か意味のある現象（例えば発現量や変異など）を得る

という意味です。

一次解析は、最初の基本的なところなので、データの精度や結果に大きく影響しますね。
以下は全て、シーケンサーの横にあるBlade Center、というベースコールサーバーで行われます。

PacBioのシーケンサー生データは、Movieです。
Movieはとてつもなく大きなデータで、1秒間に3Gbも出てきます。
これはメモリ上に展開されるだけで、すぐに圧縮されてトレースデータ、という形で保存されます。
この、Movieからトレースデータへ、「Movie-to-Trace」 という部分が、Real Timeで行われているのです！
SMRT Cell のSingle Molecule "Real-Time" ですね。

Movieから変換されたトレースデータは、それでも1Cellあたり、50～150Gbもあります。　（Movieの時間によってサイズが異なります）。
トレースデータは、各ZMWから放出された、計測したPhotonの量（光量子束、photon flux）を数値化したものです。
各カメラから計測されたPhotonの推定量と、蛍光ごとによるPhotonの推定量とを使って、何やらノイズを取り除くノーマライズをしています・・・。
これ以上説明せよと言われてもできません。　ごめんなさい！

まあ、ざっくり言うと、動画から蛍光ごとに区別した波形データを作っているんですよ！

で、このトレースデータは、まだ塩基ごとの波形がばらばらなので、もうちょっと見やすく、さらにノーマライズしたのがパルスデータです。

トレースからパルスへ、「Trace-to-Pulse」変換が行われます。
この変換の最終目的は、ポリメラーゼがDNAを読んだ時の、パルスの正確な検出と、他との区別をすることにあります。

トレースデータはまだ、塩基ごとの区別があいまいなんです。　それを、閾値を設けてノイズをできるだけ取り除き、ほかの塩基としっかりと区別できるように変換したのがパルスデータなんです。

パルスデータには、重要なKinetics情報が含まれます。例えば、

1. パルスの高さ　Intensity, or Pulse Height
2. パルスの幅　Duration, or Pulse Width  (PW)
3. パルス間の時間　Spacing, or Interpulse distance  (IPD)
4. 塩基の種類　Content, or Base identity

などです。

次にようやく、パルスデータからベースデータへの変換、「Pulse-to-Base」が行われます。

Menlo Parkにて

久々の投稿です。
ちょっと最近、忙しくて書く暇が見つからなかった・・・。　
ネタはいっぱいあるんですけれど。

そういえば先週、Menlo Parkへ行ってきました。

カリフォルニア州のベイエリアのほとり、ちょうどFacebookの本社があるすぐそばに、PacBioの会社はあります。
社員およそ300人。
開発に携わるグループは、分子生物学、光学、計算科学、など各分野からの天才がそろっています。
R&Dセクションでは、常に新しい酵素のテストが繰り返され、今まで数千を超える酵素がランされたそうです。
工場では、パーツごとに外注で作られた部品が、慎重に組み立てられていました。

私が行ったところは、主にバイオインフォのセクションと、R&D、それにITシステムのセクションです。
ポリメラーゼの開発は、特に興味深いものでした。　
Publicには書けないのが残念です。

Pacには、フィールド・アプリケーション・スペシャリスト（別名FAS）という仕事があります。
私も、実際、Pacの分け方ではFASの一部で、FASのバイオインフォ担当、ということになるそうです。
そんなこんなで、全米各地から20～30人のFASが集まるトレーニングに参加してきました。

日本ではまだPacのシーケンサーが入ったばかりなので、正直言って、どんなサポートが必要なのか、未知のことが多いです。
アメリカではもう1年以上経験があるので、ユーザーがどんな質問をするのか、どんな要求をするのか、そこは参考になりました。

IT、ソフトウェアに関しては、私も前職で経験がありますが、改良すればバグがつきものです。
バグは見つけたら直す、ということの繰り返しです。
なので、私は最近、バグを見つけることにやりがいを感じています。
幸い致命的なバグは見つかっていませんが。

バイオインフォ関係は、以前もちょこっと書きましたが、アセンブリにCelera Assembler　を使うことができます。
Celeraをやってた技術者がそのままPacに転職してきたから、使うのに慣れていた、ということもありますが、ロングリードはCeleraが向いているそうです。
そのほか、マッピングやアセンブラは、まだまだ開発の余地が残っています。
開発というよりも、既存のマッパーやアセンブラーを使うか、少し改良して使う方が、精度を上げることができるように感じました。
実際、BWAでもちゃんとマッピングできます。
CLCでもできるかな？

さてさて、Menlo Parkというところは、Facebook効果もあってか、最近物価が上がってきているそうです。　
ミリオネア（つまり大金持ち）がたくさん引っ越してきているそうです。
近隣の町のダウンタウンも、いい感じのレストランが多くありました。
そして、ホームレスがいない。
ちょっと先のサンフランシスコとは大違いです。

Facebook本社前の「いいね」看板