電顕で撮影した画像を次々処理したいということでツールを作ってみた
コンセプトは
- webインターフェース
画像保存場所とrelionらで処理する場所、パラメータを定義して実行ボタンを押下すればバックグラウンドで保存場所をwatchします。
そこに画像ファイルが来ればrelionにpbs経由で処理を回します。その間、ブラウザは閉じても構いません。
ただ測定が終わったらバックグラウンドのジョブを停止することが必要です。72時間後で自動終了も可能
- relionで処理を回す
webインターフェースには、relionの画面(Motion correction/CTF estimetion)で提供されている入力欄が用意されています
逐次処理自体もrelionのコマンド(relion_run_motioncorr, relion_run_ctffind, relion_preprocess)を使用しています
- Gautomatch/Relion Laplacian-of-Gaussian/crYOLO らで粒子をpick
逐次処理を進行させつつ、一方でGautomatch/LoG/crYOLOらで各種パラメータを調整して粒子をpickする条件を決めます(条件検討)
参照: Gautomatch crYOLO
- 定性目的な2D Classification
pick条件に従い、バックグラウンドで指定した粒子数まで粒子をpickします
指定した粒子数まで届いたらrelionの2D Classificationを実行します
これも同じくバックグラウンドで処理をするので、設定したらブラウザを閉じても構いません。
qsubに投げているので終わったらメールでお知らせも可能です
- グラフ表示
ctf後の「micrographs_ctf.star」から「_rlnCtfMaxResolution」値でグラフ・表が表示できます。閾値で画像ファイルの新リストを作れます
- 計算は全てジョブスケジューラ pbspro で行う
torqueでも可能
基本webはdhtmlxを使ってるので大抵のブラウザで動くかと.
認証が必須でAD認証を使ってます. LDAPでも動くかもしれない.
relionからMotionCor2,Gctfを使ってるので nvidia カードを持つ計算ノードは必須.
(RelionMotioncorrとctffind4でも可能)
500MBなイメージを連続(1枚/1min)で出る環境なら1070を2枚は欲しいかな. っでないと自転車操業状態.
さらに同時に2Dを行うならもう一枚は欲しいかな.
PostgreSQL/mariadb/SQLiteらのデータベースは使ってません.
撮影終了後にrelionを開くと「Import」「Motion correction」「CTF estimetion」が完了となっている画面になります
スクリーンショット †
全体像

撮影画像を右クリックしてメニュー操作すると

下記のような画面が表示されて、Gautomatch、RelionLoG、crYOLOらによる粒子のpickができる。
(各pickツールのパラメーターを調整しつつ粒子のpick具合を繰り返し確認できます)

パラメータを調整しながら何度でも条件検討が行えます。
使用するpickツールとそのパラメータが決まったら、いくつまで粒子を集めるかを指定します。
(190506更新)

指定した粒子数で2D Classificationが行われます。
また1万粒子毎とかで2D Classificationも行えます。
表現としてありかは微妙ですが、下記は横軸にclass、縦軸をiterとしてます。
(190506更新)

1万粒子毎とかでの表示切り替えは下記のようにプルダウンで行います

ctffind4,gctfの計算値からヒストグラムの表示も可能です

メモ †
参考先
Leginon
様
Gwatch
様
Relion様
参照論文
「Automated data collection in single particle electron microscopy」
https://academic.oup.com/jmicro/article/65/1/43/2579697
既知の問題と今後 †
- httpdを再起動すると逐次処理が終了する
プロセス的には離れているのだが....
- 8kイメージだと逐次処理が滞る
relionMotionCorrectionに時間を要する。1枚/1minなら16coreなマシンが必要みたい
- Laplacian-of-Gaussianでreferanceなしのpicking
Gautomatchの他にrelion謹製のauto-pickingツールを使えるようにしたい(1905 一応達成)
- crYOLOのpickもできるように
Gautomatch、Laplacian-of-Gaussian、crYOLOの3種で比較できればいいかな(1905 一応達成)
- relionでの処理をflowchart表示
既にrelionにある機能だけど、flowchartを選択すると、2D, 3Dの画像が表示されるとかしようかと
*ジョブの発行機能は持たせないつもり。あくまでも表示と逐次処理をメインにしたい。以降の作業はRelionの画面で行うのがいい。使い勝手もいいしね
- dhtmlxEnterpriseLicense機能抜き版をオープンソースに
需要が微妙だけど、オープンソースにします。ただ、現状dhtmlxEnterpriseLicenseが入ってますので、それを除いて
dhtmlxGNUGPLライセンスで使えるようにする必要がある。こちらはsiloのソースを出して、受けて側がdhtmlxを用意頂ければいいかなと。
ソースの提供方法ですが、、、問い合わせがあれば渡します。問い合わせ先はこのサイトのトップページに書いてます。
- relion_it.pyがあるけど...
本家様にはかなわない. 違いはweb環境で使うかどうかだと思う. 正直web環境を用意するのは大変ですから、Gwatch、relion_itの
逐次処理は非常に便利だと思ってます. siloの利点はブラウザがあればいいとか位でしょうか.
トリガー †
web画面のボタンをポチッと押せば、それが全体のトリガーとなるのだが、より細かい内容を明記すると
「ポチッ」と押下した後、特定のフォルダを監視します。
ファイルが電顕から届いたら inotify-tools で「CLOSE_WRITE,CLOSE」を確認して、ジョブコントロール(PBSpro)へ処理を流します。
ですから、ファイルが届くたびにジョブが発行されるのですが、このジョブは「その届いたファイルを処理」するのではなく、
「未処理のファイルがあったら実行する」内容になっている(relionの「--only_do_unfinished」を活用)
初回は、届いたファイルのみを処理するであろうが、二回目のジョブはそれまで届いたファイルを処理します。
そうなると余分なジョブが発生してしまうが、それを抑えるために、ジョブ発行数は6本までとかに制限しています。
留意点
ジョブを発行するタイミングをinotify-toolsの「CLOSE_WRITE,CLOSE」に依存しているので、
電顕から届くファイルはLinuxファイルシステムに置く必要がある。
電顕から届くファイルがwindowsServerに溜まるので、それをwindowsOS提供のnfsでexportして、linuxがそれをnfs mountすれば、
監視ができるかと思ったのだが、無理でした。同様にwindows共有で提供して、linux側からsmbmount(cifsmount)しても駄目だった..
この場合、linux側でsmb共有フォルダを用意して、そこにwindows側が書き込めば大丈夫となった。
参照inotify-tools/WindowsPC
(1909)この部分に修正を加えた。電顕からのファイルを溜めるフォルダをwindows共有させ、cifs mountでマウントさせ、
60秒に一度とかで rsync を発行させるようにした。inotify-toolsを使ったトリガーには変更ないが、
windows側にあるファイルをsilo側でrsyncを使って持ってこさせた。
これでwindows --> siloサーバ(Linux) への転送アプリを使わなくても大丈夫。
relionMotionCorrection †
次のイメージファイルが届く前に計算を終えさせる必要がある。
relion謹製MotionCorrで4k,8kでの計算時間を調べてみた。
結果、4k画像であれば、2coreで [1枚/1分] に十分に間に合いそうである。
263MB 4k画像ファイル, Ryzen7(8c/16t), gcc |
core | 1core | 2core | 3core | 4core |
time | 62sec | 30sec | 22sec | 16sec |
次に8kの画像であるが、intelマシンではこうなった
530MB 8k画像ファイル, i9-7960X(16c/32t) | コンパイラ |
core | 4core | 8core | 16core | |
time | 2m47.646s | 1m32.670s | 1m5.247s | gcc |
time | 1m16.285s | 0m44.405s | 0m34.189s | icc |
同じデータをRyzen7で回してみた
530MB 8k画像ファイル, Ryzen7(8c/16t) | コンパイラ |
core | 4core | 8core | |
time | 2m3.169s | 1m19.468s | gcc |
time | 2m0.333s | 1m20.464s | gcc7 |
time | 2m12.625s | 1m30.408s | icc |
どうも8kで回すにはハイスペックが必要みたい...