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やマシン増強などに走る傾向があるので、注意が必要だが。