GPUの増設検討メモ

Mac miniでMinIONデータのベースコールをliveで行なっているが、一週間過ぎた現時点でも50%ほどしか進んでいない。これだと、48hほどランしたwhole genome DNA-seqのデータをベースコールするのに二週間以上かかりそうだ。これではちょっと不便だが、Nanopore communityの情報を見ていくと、CPUを使ったベースコールはだいぶ時間がかかるようだ。それに加えるとGPUを使った場合はかなり時間が短縮されるようだ。

性能の高いGPUは、機械学習にも使うことができるようで、この際GPU増設を行おうかという気になっている。ベースコールに使う場合、そもそもLinuxしかGPUを使った計算はできないらしい。しかもUbuntu限定のようだ。現在運用中のLinuxはcentosなので、もしMinIONのベースコールを行うのならOSごと変えないといけない。プラス、SSDのアップグレードも必要だろう。

とりあえずnanopore communityの情報などをもとに、GPUについて調べた。

• https://community.nanoporetech.com/posts/gpu-for-basecalling に情報あった。
• CUDA capability of 6.0 or greate が必要らしい。
• 中の人は、GeForce RTX 2080Tiを使っているとある。
• また、Nvidia quadro RTX8000がサポートされているかとの質問には、使えるだろうという回答。CUDA 7.5だから。

NVIDIAのCUDAの確認は、以下のサイトからできた。

• https://developer.nvidia.com/cuda-gpus#compute

GeForce RTX 2080Tiは、１２〜１８万円くらいみたいだ。なかなかの値段。これに、SSD追加費用などを含めると、20万円ほどになるのではないかと思われる。

CUDA 6.0以上ということなので、もう少し安価なGPUを探すこともできるだろう。
以前WSを買ったUnivのサイトで、アカデミック限定でNVIDIA Quadro RTX 6000/8000のキャンペーンをやっていた。これは38万から55万円。オーバースペックかもしれない。

他の解決方法

•  他研究室の先生と話していたが、CPUオンリーの計算で済ますとして、何台ものPCにfast5データを分けて並行してbasecallしたらいいんじゃないかという話が出た。PCを購入する必要が出てくるが、PCは他のことにも使うことができる。
• もう一つの解決策は、Nanoporeが売っているMinITを買うことだろう。GPU accelerators (ARM processor 6 cores, 256 Core GPUとある。ただ、他の用途には使えないだろう。

MinKNOWの.rawファイルを.fast5ファイルにリカバリーする

前回MinKNOWを使用した際にランが不正終了してしまい、同時に行われていたベースコールも途中でとまってしまった。この際にquened_readsというディレクトリの中に.rawという拡張子がついたファイルが大量に残されており、ファイルサイズからもここにベースコールされていないデータがあると思われた。情報を検索してみると、biostarsにポストがあり、nanoporeのコミュニティサイトのなかに詳しいリカバリ方法が示されているということだったので、そちらの情報を参考にしてデータのリカバリーを試みた。

手順

communityのポストの情報を見ると、MinKNOWの中に、recover_readsというプログラムがある、と書いてあった。場所はポストの情報とはやや異なり、

/Applications/MinKNOW.app/Contents/Resources/bin/recover_reads

だった。これを使って.rawを.fast5に変換できるらしい。

このプログラムを使うには、--template-readオプションを使えと書いてあった。最初どういうことかよくわからなかったが、当該ランで作られた.fast5ファイルを何か指定して、ランの情報を見るために使われるらしい（多分）。そこで、MinKNOWフォルダ下にあったfast5_passのなかに入っていたファイルを一つ適当に選んで使うことにした。

ライブラリのフォルダのなかにMinKNOWというフォルダが作られているが、そこにqueued_readsというフォルダがある。ここの中に、complete_reads_c1ff7110-263a-4625-9a8c-f5292a179a27といった感じの名前のフォルダが作られている。この下に.rawという拡張子のついた大量のファイルがあり、今回のランの場合合計で140GBくらいの大きさになっていた。これに対して、

recover_reads --template-read ./template_read.fast5 ./queued_reads ./revovered_reads

といったランをおこなう。この作業によって、recovered41c77748-25e7-49ce-b87b-14af63a20c38<番号>.fast5という名前のファイルが生成される。この.fast5ファイルを使って、guppy_basecallerによってベースコールをおこなうということも可能だそうだ。サイズはかなり大きくなる。CPU負荷はそれほど大きくはならないようだ。

参考URL

https://www.biostars.org/p/388640/

https://community.nanoporetech.com/posts/how-to-convert-raw-to-fa

MinIONラン中のエラー（Error connecting to position)

MinIONをランしている途中でエラーが発生して、シークエンシングとベースコールが中断されていた。そこで一度MinKNOWを終了させ、Macを再起動したのちにデバイスが使えるかどうか復帰テストランをした。テストランは無事に終了したので、デバイス側の故障では無いようだった。記録のために以下に経緯をまとめる。

（１）エラー発生

• ラン時間を48時間としてランをDNA-seqを開始した。数時間おきに様子を見たところ、ランは正常に進行しているようで、アクティブに読んでいるポアの様子を確認できた。30時間経過後に確認した時点までは正常にランしていた。
• 次の日に研究室に行くと設定したラン終了まであと数時間残っているはずなのに、ランが止まっていた。アクティビティモニタで確認すると、プロセスとしてはguppyやMinKNOWがあるが、CPU稼働は０近くに落ちていたし、本当にランしていないようだった。
• その時のMinKNOWの画面は以下の通りで、デバイスが認識されておらず、”Error connecting to position"のメッセージが出ていた。

ここからactive runの画面にいこうとしても、以下のメッセージ（Loading run data）が出ていつまでも変わらない状態だった。return to sequencer selectionのボタンを押して元に戻るしかなかった。

（２）状況確認とデータのバックアップ

• いつ頃ランが不正終了したのかを推測するために、ライブラリ下のMinKNOWのディレクトリの中を覗くと、ベースコールが終わったファイルが４つほどあり、ベースコールを待っている.RAWのファイルがqueueのディレクトリの中にたくさんあった。その中の一番新しいものの生成は午前4時だった。ラン終了予定に6~7時間残しくらいでランは終わっていたようだ。ベースコールされたfastqファイルも同様に確認したら、同じくらいの時間で生成されていた上に、ファイルサイズが前のファイルと比べてだいぶ小さかった。同時刻にベースコールも不正終了したようだ。
• 一緒にランを行なっていた他研究室の先生がnanopore communityの情報を調べたところ、MinKNOWのアプリケーションの更新を行なったあと再起動していないと問題が起こるケースがある、またはデバイスの側が壊れている可能性がある、との情報があるらしい。とりあえず、現在のraw dataやベースコールされたデータなどを全てバックアップしたのちに、アプリケーションを終了してmacを再起動してみることにした。

（３）MinKNOW終了、mac再起動、テストラン

• データのバックアップが終わったので、デバイスのusbケーブルを引っこ抜き、MinKNOWを終了した。その後、通常の動作でmacを終了させた。
• 再度電源を入れ、MinKNOWを起動させた。みる限り問題が無いよう。デバイスusbを接続すると、正常に認識された。
• 試しに、そのままのflow cellの状態で再度1時間ほどの設定でランを行なってみることにした。前回の最後の方の電圧を入力し、ランを開始すると通常どうりランが始まった。ステータスを見ると、ポアの数はかなり減っているが、アクティブなポアもあり、すぐにリードのヒストグラムが現れた。
• その後ランは1時間後に正常終了した。その後もベースコールは継続中。

（４）考察

• 復帰後正常にランができていたため、デバイス自体の故障では無いらしい。flow cellも壊れていないようだ。
• poreがかなり少なくなっていたがそれが原因というわけでも無いようだ。
• 最初のランの前にMinKNOWのアップデート通知が来ていたので、ボタンを押したところ、不自然な形で一度アプリケーションが閉じてしまっていた。再度アプリケーションを立ち上げデバイスを抜き差ししたところ、普通に認識されていたのでランを始めていた。macの再起動はしていなかった。
• MinKNOWのアップデートの時にosごと一度再起動していなかったのが問題なのかもしれない。なぜ40時間以上経過後に始めてバグったのかはよくわからないが。
• 残っているraw dataは手動でベースコーラーを使う必要があるだろう。そうしたら、設定より数時間は短くなってしまったが、大部分のデータは使えるだろうと思われる。
• 2日以上たっても、flow cellの中にはライゲーションされたgDNA サンプルが残っておりランも可能だった。

MinIONのactive poreの数

MinIONのセットアップ後、他研究室のサンプルが初めてシークエンスされた。今回は、マメ科植物の根粒菌を研究している研究室のランのサポートをした。根粒菌のゲノムDNAを高分子DNA抽出キットで抽出後、short read eliminator で精製したものが持ち込まれた。ライゲーションのプロトコールでランした。前回使用したのちにwashキットで洗っておいたflow cell を使用した。flow cell チェックではアクティブなpore数は920個程度と基準値を超えていた。実際にランを始めると、下の図のようにinactiveなporeが固まって出てきてしまった。

 inavtiveなporeの割合はおおよそ３割程度のようだ。

空気の泡が流路に混入してポアに流れていってしまうとすぐに使えなくなってしまうと書いてあったが、これはその症例だろうと思われた。前回のランでは全体的に緑のシークエンスされているポアばかりになっていたので、ラン終了後のwashから、新しいサンプルのアプライまでのどこかでバブルが混入したのかもしれない。勿体無いが３割程度のporeはロスしてしまったようだ。

１時間すぎたあたりでランの途中経過を確認した。

 ごく短いリードが少ないのは、short read eliminatorの精製によるものかもしれない。10Kb ~ 50Kbくらいのリードに加えて、200Kb近いリードも読めている。ランは48時間に設定したが、明日どの程度のリードが読めているか楽しみだ。根粒菌のような小さめのゲノムの場合、ロングリードを読むだけでアセンブルまでできるかもしれない。

LinuxマシンのRAM増強

解析に使っているLinuxマシンには96GbのRAMを積んでいて、だいたいそれで間に合うのだが、ゲノムアセンブリの際のショートリードを使ったpolishingや、RNA-seqデータ等のde novo assemblyには不足していて、途中でエラーを吐いて強制終了していた。そこで、メモリの増強を行うことにした。増強前に積んであったのは8Gbメモリ12枚だったのだが、とりあえず16Gbメモリを４枚買って残りのスロットに刺してみることにした。うまくいったら、予算に応じて残りのスロット分も買い足して、最終的には256Gb RAMにしようと思っている。買い足したのは、16GB module DDR4 2400MHz ECC CL17 288-Pin Server Premier (Kingston, KSM24RD8/16MEI)。最初に購入した時に刺してあったのがKingstonだったが、他のメーカなら同じ規格でもっと割安な製品がある。多分大丈夫なのだが、何がしかの相性問題が出た時に解析そのもの以外のところで時間を使うのも面倒だったので、メーカーは統一した。少し前に電気店に行った時に買ってあった静電気防止手袋をつけて作業した。

ネジを２つ外して側面のフタを開ける。この前もだったが、青いレバーをあげながらスライドさせないと開かない（いつも忘れてしまうので記録しておく）。

 RAMのスロットは４つ空いてい流のでそこに刺す。いつものように全体を軽く掃除する。前回から時間が経っているせいかファンや通気口には埃が溜まっていた。ブローやアルコール拭きで簡単に取り除いていく。まだHDDは１つ空いている。最近のPCのSSDの威力を目の当たりにしているので、すでにHDDで使っているベイも合わせて３つを全部SSDに付け直して使ったら使いやすくなるかもなと思っている。

 最後に蓋を閉めてケーブル類を元どおりに繋いでいく。メモリの確認は、

dmidecode --type memory

で行う。全てのスロットで無事メモリが確認され、新しく増設した16Gb x 4も無事使えるようになった。

いつの間にかCent OSは8がリリースされる

現在LinuxではCentOS 6.7を使用している。

7に上げようか迷っているうちに、centos8が出たらしい。ブログなどを読むと、アプリケーションのインストールに使われていたyumがなくなり新しいコマンドが使われるなど、結構変更点があるようだ。centosにこだわらずにubuntuに乗り換えるべきかも含めて、どのタイミングでosのアップグレードを行うか迷っている。クリーンインストールになると思われるので、とりあえず現在行なっている解析が終わり、かつ時間の余裕ができた時だろう。でも、過去の経験から言うと忙しい時ほど（逃避的に）OSやマシン増強などに走る傾向があるので、注意が必要だが。

中国系のゲノムデータベースのサイトBRADが現在利用不可

Brassica rapaのゲノム情報を公開しているBrassica database (通称BRAD）というサイトがある。Brassica rapaについては、欧米系のポータルサイトもあるが、いわゆるハクサイ（Chiifu）のゲノムを解読したのは中国の研究グループで、標準の情報もそちらのサイトに集約されている。ときかく中国系の研究グループはパワフルで、標準系統だけでなく多数の系統のリシークエンスデータを読んで論文を出し続けていて、とても他の国の研究者が敵う感じではない。で、そのゲノム情報がまとめてあるBRADのサイトをよく使っているが、今日久しぶりに見てみたら、以下のようになっていてサイトにアクセスできない。

 中国語のメッセージで、しかも簡体字だと何を書いてあるのか分からない。で、google翻訳を中国語で使ってみることにした。すると、

 すごく流暢な和訳が返ってきた。どうも、中国の法規に引っかかるものがあって利用できなくなっているようだ。ハクサイゲノムの情報を公開していることと何か関連があるのだろうか？日本語訳された情報がいわくありげな感じで想像力が掻き立てられるが、いつになったら再開するのだろうか？

Google翻訳を前提にした非英語情報のネットサーフィン

先日にも書いたが、google翻訳はすでに実用的な段階になっている。今回はgoogle翻訳があるおかげで現在の状況の把握ができた。中国語だけでなく、自分が知らない言語について助けになることが身を以てわかった感じがする。これまでにも、翻訳サイトを使って海外のブログを読んでいる人がいるとか、海外サイトを見ている人がいるとかは知っていたが、うかつにもあんまりピンと来ていなかった。海外サイトを見るにしても、英語情報で事足りる場合が多かったし、英語ならばそこまで翻訳サイトを頼る必要がなかった。逆に言えば、英語以外の情報はあまり注意して探してみようとしていなかった。これからは何か情報を得たいときに、google翻訳が使えることを前提として、英語圏以外のサイトも見るのが当たり前になっていくのかも（自分が疎いだけでもうみんなそうしているのかもしれないけど）。
多分、分かっている人には前から分かっていて、すでにそういう風に行動しているんだろうなと思った。

逆説的だが、非英語圏のネットワークを探していくために、キーワードとなるとっかかりの単語や、簡単な知識は逆に色々な言語であったほうが良い気がした。言い回しとか、文化的な背景とかで、日本語そのままの発想だと適切なキーワードが思いつかない場合もあると思う。

これからの語学学習は、やはりこういう翻訳技術があることを前提にして、それらを役立てる方向で進めたほうが良いように思った（スタンドアロンで読み書き会話ができる、というのが目的ではなく）。

科学研究で中国のデータベースが普通に使われる現代

もう一つ思ったのが、ゲノムデータベースとして、中国の研究者が運営するデータベースサイトが研究分野や対象によってはもう普通であるということを改めて認識したことだ。今回のBrassica rapaのゲノムデータについてはまさにその通りで、リファレンスとして普通に使われている。そして、このエラーメッセージからは、何がしかの法的規制によってサイトが使えなくなったことがうかがえた。同様のことは欧米や日本の場合でも起こりうるのだろうが、基礎科学のデータベス、それもハクサイゲノムのデータベースでこのメッセージを見たことにとても強い違和感を覚えた。中国は科学技術の研究に多額の予算を費やしていて、日に日に存在感を増している。これからの科学研究で中国発のデータにますます頼るようになった場合に、中国の法規や国内事情によってそれが使用できなくなり研究に支障が出る、というようなことが現実として普通に起こるようになるのかな、とふと思った（今回のサイト利用できなくなった件の理由はよく分からないので、もっと単純な理由なのかもしれないが）。