配列パターン検索はUNIX的にはgrepでできるが、バイオな配列に対してだと、パターン中に改行が入った場合やヘッダ行中の「誤爆」を防ぎたい。さらには、いくつかのミスマッチも許容するには、EMBOSSパッケージのfuzznuc(塩基配列)やfuzzpro(タンパク質配列)を使えばよい。例えば、1塩基のミスマッチまで許して、AGGTCAというパターンをFASTA形式のファイルhoge.faに探す際には以下のようにする。 [shell] fuzznuc -sequence hoge.fa -pattern AGGTCA -pmismatch 1 -outfile hoge.fuzznuc [/shell] -pmismatchというオプションがキモ。
もちろん、ChIP-seqのデータがあればそれを利用すればいいのだが、多くの場合そういったデータのない非モデル生物種では、転写因子の結合の有無を調べるのに、転写因子結合サイトを予測する。 TRANSFACがそのデータベースとして老舗だが、有料になっている。 しばらくフォローしてなかったけど、JASPARが良くなっている。JASPAR CORE databaseとしてVertebrata, Nematoda, Insecta, Plantae, Fungiと生物グループごとにセットが分けられていて便利になっている。それ自体は狭山茶やっていた10年前に比べて増えているが、予測法自体は変わってない模様で、やはり閾値は自分で決めないといけないのと、生物学的にはfalse positiveが多い。
モデル生物ではきっちりアノテーションがなされ、UTR(UnTranslated Region)の配列抽出とか、EnsemblのBiomartを使えば簡単にできる。Ensemblにない生物種でも、Ensembl Genomesのそれを使えば良いのであるが、こちらの場合生物種によってはUTRのアノテーションがなくて抽出できないことがある(あった)。アノテーションがきっちりなされていない非モデル生物のUTRの配列抽出は大変である。 しかしながら、簡単にやる方法があった。それなりにdeepなRNA-seqデータがある場合に、であるが。それはTrinityによるde novo transcript assemblyとその結果を元にOpen Reading Frame(ORF)を予測するTransdecoderによるアノテーションを利用するというものである。Transdecoderを実行(過去のブログエントリ参照)した後に出て来る結果のGFF3形式の出力をBEDファイルとして保存して、それを元に部分配列抽出する。 [shell] grep UTR Trinity.fasta.transdecoder.gff3 > UTR.gff3 bedtools getfasta -fi Trinity.fasta -bed UTR.gff3 -fo UTR.fasta …
割とすぐに終わるからこれまで特に気にしていなかったが。調べてみたら、やはりsamtools indexもスレッドオプションがあった。他のコマンドと同じで-@のあとに上限スレッド数を指定する。この例の場合、4。 [shell] for f in *.bam; do samtools index -@ 4 $f done [/shell] 並列化の効果あって、結果が得られるのが早くなった。「indexがない！」と別のアプリケーション(例えば、IGV)で怒られてindexを作ることが多いので、早く返ってくるのは嬉しいかと。最初から作っとけよ、という話もないではないが…。 複数のファイルを引数指定できるといいのだが、上述のように書けば済む話なのでよしとする。
今日から5月。絶好のデータ解析日和ということで(^_^)。 TopHatの結果を処理するコマンドは以前はやっつけでinteractiveに処理していたが、バッチ化というか並列化というか。中間ファイルがかさばるのでパイプライン処理して一気にsortされたファイルだけを出力しようということで先日覚えた-(マイナス)オプションの練習がてら。 状況としては、TopHatの結果のBAMファイルがhoge1,hoge2,hoge3のようなディレクトリの中にaccepted_hits.bamというファイルで入っているのが前提で、そのディレクトリがあるところと同じ階層にhoge.bamというファイル名で新規のソートされたBAMファイルを作成する。
1 2 3 4 5 6 | |
というスクリプトをsamtools-merge_sort.shという名前で保存して、 [shell] sh samtools-merge_sort.sh …
ファイル変換weekになってしまったので、BAMからCRAMへのバッチスクリプトも紹介しておく。 SAMBAM変換とは異なり、リファレンスゲノム配列が必要で、それは各環境で違う場所にあると思うので、それは自分の環境のそれを指定しないといけないことに注意。
1 2 3 4 5 6 7 8 | |
上記のスクリプト(bam2cram.shとする)を、BAMファイルの置いてあるディレクトリに移動してから、実行する …
SAMからBAMに変換して、そのまま中間ファイルを作らずにBAMをソートする。それをバッチで処理するには。 SAMファイルの置いてあるディレクトリに移動(cd)してから、以下のようなスクリプトを実行。
1 2 3 4 5 6 7 8 | |
samtoolsの行の一番最後の-(マイナス記号)がポイント。これが標準入力から入力を受けることを示すコマンドで …
現在お世話になっている研究所でOxford Nanopore Technologies のセミナーがあり、参加させていただいた。 大変興味深く聞かせてもらったが、MinIONからの塩基配列データはFAST5という形式で出てくるらしい。そのFAST5から、一般によく使われる配列フォーマットFASTQへの変換をするには、poretoolsというのを使えばよい、となかのひとに教えてもらった。そのporetoolsはやはりHomebrewにあって、 [shell] brew install -v poretools [/shell] でインストールできる。 Usage examplesにあるように [shell] poretools fastq test_data/*.fast5 [/shell] で変換可能。
ぼうのブログによると、2009年の7月29日に初めてDBCLSに来てくれた当時M1の学生さんだった。その後、Research Assistantとして統合牧場でUNIXとしてのMacの使い方を身につけ、そして学んだことをブログや統合TVとしてまとめてくれた。その後、そのままDBCLSに残ってくれて、後輩RAの指導、ときには自ら統合TVのコンテンツとなり、統合DBプロジェクトを盛り上げる一方、Sequence Read ArchiveのデータをFastQCで計算してその結果を可視化する、というプロジェクトに挑み、それを論文という形にすべく頑張ってくれた。 そして本日、ついに筆頭著者論文をpublish。おめでとう!今後、ますますの活躍を期待しています。
ついにこの日がやってきた。各所に働きかけた末に。
That's one small step for (a) man, one giant leap for mankind.
ただの盛り上がったミーティングに過ぎないと思われるが、実はそうでない。 これから快進撃が続くことは、すべて「ゼーレのシナリオ通り」なのである。
配列データ解析、頑張らないと。それを後押しする事象発生。折しもそれ関連の計算を始めていたのは、虫が知らせたか?自分自身の解析からそういうのが見つけられるかどうか、正念場。しまっていこう。
昨日のエントリの続きで、複数のBAMファイルをCRAMに変換し、そのサイズを比べてみた。
それぞれのファイルサイズを同一行に来るように1行ごとにデータを作って(cram.txtとbam.txt)、その圧縮率をちゃらっとawkで計算。 [shell] paste cram.txt bam.txt | awk '{ print $1,$2, $1/$2 }' [/shell] 結果が以下の通り。見ての通り、3カラム目がその圧縮率となる。
5660626395 9438014937 0.599769
4654129817 7896095631 0.589422
5087289649 8493424101 0.598968
5002310872 8382697420 0.596742
4117487398 7031097146 0.585611
4507556734 7565563208 0.595799
502823996 …BAMからCRAMへの変換を試してみた。samtoolsを使えば良いだけの模様。 [shell] samtools view -@ 4 -T hogenome.fa -C -o hoge.cram hoge.bam [/shell] 3,091,833,154byteあったファイルサイズが、2,325,565,061byteに。約75%になったとは、すごい!CPU時間的には
263.48s user 45.58s system 205% cpu 2:30.72 total
複数CPUを指定効果もあったようだ。これぐらいの時間なら普段はCRAMにしておいて使うときだけBAMというのが実現可能か?
また、逆にCRAMからBAMへの変換もsamtoolsで。 [shell] samtools view -@ 4 -T …
dottupの説明を書くため、EMBOSSのチュートリアルを見ていたら、XL23808というアクセッション番号の配列が使われていた。チュートリアルに出ている配列だし、自分もこれで例を作ろうと、これが何かをDDBJ/ENA/GenBankで検索しても、ググっても出てこない。 別ページにあったFASTA形式のファイルのヘッダにある機能アノテーション情報
Xenopus laevis rhodopsin gene, complete cds.
からググって解決。なんと、IDにもinsertionが入ってXLU23808になっていたというオチ。 そういえば、RefSeqも始まった当初から数字の部分の桁数が増えて、システムによっては異なる遺伝子がリンクされたりということがあったな。 諸行無常である。
直接は被っていないものの、それでも学生委員会の同窓会で最近も何回か会った、同学年の同志の訃報。そんな私にも誕生日メッセージを送ってくるなど、私などは足下にも及ばない気配りの人でした。 またアウトリーチ活動に力を入れていた草の根研究者で、私の今の職場のような研究機関で働いていることをいいというばかりか、羨ましいとまで言ってくれた数少ない知己だった。 彼の分も、そっちも頑張ろう。自分がやれることから、微力だけれども。 お悔やみ申し上げます。
米国のアウトリーチ活動に関して、2016年9月のICE2016に参加した時に紹介してもらった Library of Life Collection Card が断舎離していたら出てきた。 このサイトからもリンクのあるアプリ「Libraries of Life」をダウンロードして(ANDROID版もある)、やはりそのページからリンクされているSPECIMEN CARDSのPDFもダウンロードして、紙に印刷するか、パソコンの画面で表示するかして、さきほどのアプリからカメラを起動してそれをかざすと…。 標本(Specimen)が3Dで見ることができるんですよね、これ凄い!ぜひ、日本でもこういういいものは真似してアウトリーチ活動に取り入れるべきかと。
AWSに移設したAOE2の更新ができるように、いろいろと準備してもらいつつ。昨日やったことのまとめ。 AWSにsshできるように/Users/hoge/.ssh/configに以下の設定を追記。
host fuga
user ec2-user
hostname xxx.xxx.xxx.xxx
identityfile /Users/hoge/.ssh/fuga.pem
そして [shell] ssh -i /User/hoge/.ssh/fuga.pem fuga [/shell] とすると入れるようになった。
AOE2いよいよ公開へ。セキュリティ強化と停電のないサーバーでのサービスを、ということでAWS化を急遽。達人たちに教えてもらい、AWSでセットアップしてもらう。いろいろと設定を教えてもらい、そしてついに初のAWSへのssh。 それと並行してAOE2用のデータファイル作成スクリプトをまとめてArrayExpressをミラーしてきているサーバーで環境を構築。うまく動いたようで、引き続き微調整。DNS切り替えなどは明日以降に。 近隣のバイオインフォマティクス始めました、な人にSPARQLthonの雰囲気みてもらうべく、招き入れたり。もっと色んな人が出入りできるアツマリにしていきたいね、今後とも。
これまで試したことなかったが、EnsemblでもTrack Hubsが使えるらしい。 追加する際に見に行く先の Track Hub registry はかつてのDAS registryのように各ゲノムブラウザー(といってもUCSC Genome BrowserとEnsembl Genome Browserの2つだけだが)共通の模様。最近はヒトやマウスだとUCSCを使いことが多く、気が付かなかった。Ensemblご無沙汰といってもヒトやマウス以外の非モデル生物ではよく使っているのだが。
ショッキングな統計値を教えてもらった。国の機関サイトの残存率というもので、5年残存率は40% (2015年)というものである。つまり半分以上は5年経つと消えるということだ。 これは、国立国会図書館がインターネット資料収集保存事業として調べ続けているもので、他には保存した1万サイトの可視化というウェブ魚拓を取っているものもあってなかなかおもしろい。資料として、説明する際の拠り所として、役に立ちそう。
Trinityを実行する際にFASTQのヘッダが問題となる事例。以前から同様の事が起きており、その場合は、 [shell] bzcat file.fq.bz2 | awk '{if(NR%4==3) $0=sprintf("'"+${index}%d"'",(1+i++)); print;}' | awk '{if(NR%4==1) $0=sprintf("'"@${index}%d"'",(1+i++)); print;}' | bzip2 -c > file2.fq.bz2 [/shell] のようなコマンドでヘッダを書き換えしのいでいたが、これが今回効かず。
ちゃんとSRAからダウンロードしてきたFASTQファイルなのに、Trinityでエラーが出て先に進めないなんて、と思ってエラーメッセージを眺めていたら、
If your data come from SRA, be …
未来永劫続くプロジェクトやデータベースはないとはわかっていても、その継続を仮定してしまうのはなぜだろう。 調べ物をして知ったのだが、GDBというデータベースは、ヒトゲノム情報の集積場の「Genome Data Base」として作られていたのに、GDBは使われなくなり、なぜかカナダに行って、その後2008年には無くなっていたとか。 また、Ensemblは開始以来、European Bioinformatics InstituteとThe Wellcome Trust Sanger Instituteの共同プロジェクトだったのに、Sanger Instituteは2016年に共同をやめ、2017年の今は関わっていないとか。イギリスのEU離脱が関係しているのだろうか。 こういうふうに思うのは、日本人の国民性だろうか? 昨今の国際情勢からして、今後いろんなプロジェクトや重要なデータベースが続かなくなったときにどうすべきか、対策を考えていく必要があるだろうと思い巡らせたり。
DBCLSが三島の国立遺伝学研究所に移転した2014年から毎年の参加で、これで4回目。しかしながら、雨になったのは初めてと。 去年に引き続き、公開講演会の撮影補助。もちろん撮影にかかわる人的なコストはかかっているが、こういう形で所属ではないが普段お世話になっている宿主の研究所に貢献できるのはよいことだという認識。後に統合TVコンテンツの一つとなることだし。 それにしても今日の講演の最後でデバ(ハダカデバネズミ)の話が出てきたのはビックリした。そのネタで科研費の研究分担金も貰っている自分としては頑張って研究を進めねば、と襟を正した次第。頑張ります。
昨日のDBCLSの論文数の検索と同じことを遺伝研でやっていみると…。
https://www.ncbi.nlm.nih.gov/pubmed/?term=National+Institute+of+Genetics[ad]
遺伝研ほどヒット数が多いと、右上に年ごとのヒストグラムが出るようです。 I先生が書かれていたように、最近数年間でaffilicationの扱いが変わったのか、論文数が多くなっているように見える結果に。何れにせよ、この研究所はコンスタントに論文を出してきている研究力のあるところだというのは間違いないようです。
とあるtweetがきっかけで、所属としてDatabase Center for Life Science (DBCLS)が載っているPubmedエントリを抽出してみた。
https://www.ncbi.nlm.nih.gov/pubmed?term=Database+Center+for+Life+Science[ad]
というURLでリストされる。2017年4月6日現在43本あって、1本を除いてすべてOpen Accessという徹底ぶりは凄い。みなさん、さすが。E-utilsでの取得も同じように。
最初の20件しか入ってないけど…。全件取るには工夫が要りそう …
まずはChIP-Atlasで調べる。目的の転写因子があれば、ラッキー。 ない場合は、"転写因子の遺伝子名"+"ChIP-seq"をqueryとしてNCBI GEOで検索。ヒットしてきたエントリを見ていって、ChIP-seqのデータがあるものを探す。FASTQ形式の生データに加えて、peak call後の解析済みデータ(多くの場合、bed形式)があればラッキーで、macs2などによる再計算不要。それをダウンロードする。圧縮は解かなくてもいい。 その場合、どのバージョンのゲノムに対して計算されたものかを原著論文にあたって調べる。そのバージョンのゲノムをUCSC Genome Browserで選択し、Custom trackとしてそのbedファイルをアップしてみると、ChIP-seqのpeakがゲノムブラウザ上に出現するように。
ふとtwitterのタイムラインを見た時に「オンラインLaTeXエディター“Overleaf”：論文投稿プロセスを変革する共同ライティングツール」という日本語論文が情報管理に掲載されたとその筆者のつぶやきが目に止まった。 論文タイトル通りOverleafというツールの紹介で、一言でいうと研究者版Google Docsという触れ込みに興味津々。さっそくアカウントを作ろうとするとTwitterやORCIDなどでログインできるではないか！！というわけで、ORCIDでログインすることで、あっという間にアカウントが作成できてしまった。 現在、Academic journalのテンプレートを使って今度投稿したい雑誌のそれを落としてきて使おうとしているところ。情報科学系な同僚はすでに使っていたらしく、無料で使える容量は少ないが便利だとのこと。 LaTeXは博士論文を書いて以来使っていないが、またこの機会にこのOverleafで使ってみようと決意。次の論文からではあるが。
The New England Journal of Medicine に掲載された論文(sounding board)、"Data Authorship as an Incentive to Data Sharing" doi:10.1056/NEJMsb1616595。 Data Sharing に関わる Incentive として Data Authorshipを、というわかりやすい考え方が Figure 1. Credit for Data Sharing and Tracing the Data Set にまとめられている。 データを出した人をrespectしつつ、それを再利用し、科学の発展を加速する。データを再利用することを推進し、自らも実践している自分にとって、とてもsupportiveな内容で、自分たちのやっていることを後押ししてくれている論文。 このFigure1はきっと、今後の発表でも多用することになるに違いない …
三島も4年目に突入。年度頭から締め切りに追われているが、ブレインストーミングに温泉インフォマティクス研究会単独開催。火の付いた仕事を効率よく進めるための頭の整理になったかと。あとはひたすらinput!
天気も荒れ模様に向かうようで、まさに春の嵐。ともに荒れて欲しくないが…。
なべて世の 風を治めよ 神の春
個人情報保護ということで、電子メールで添付ファイルを送付する際もパスワードを付けて、と言われる時代に。早速、必要になったので調べた。
例えば、hoge.jpgというイメージファイルを送る際には、まずzipファイル(hoge.zip)を作成して、zipcloakというコメンドでパスワードが必要な処理をすれば良いらしい。 [shell] zip hoge.zip hoge.jpg zipcloak hoge.zip [/shell] ググって上位に出てきたこのサイトを参考にした。
実は、zipコマンドの-eオプションを使えば１コマンドで済むらしい。 [shell] zip -e hoge.zip hoge.jpg [/shell] 上記のサイトを見て、さらにディレクトリ単位で、と思って検索してて見つけたこのサイトに書いてあることを参考にした。
パスワードを付けたzipファイルは、付ける前と同じファイル名なので、ちゃんとパスワードが付いているか、確認したほうが良いのはいうまでもないだろう。
また、ファイルが複数ある場合はディレクトリ(フォルダ)を作成してそこに置いてzipファイルにしてからzipcloakを実行すればよい。hogedというディレクトリ以下のファイルをzipで固めてパスワードを付ける例。 [shell …