HINGEアセンブラ - macでインフォマティクス

　ゲノムアセンブリは数十年にわたり計算生物学の中心的課題であったが、最近のロングリードシーケンス技術の出現で、完全なアセンブリを自動入手するという目標を達成している。しかし、リピートを確実に解決するために、エラーが頻繁に発生するリードに存在する情報を抽出することは依然として課題となっている（Myers 2016a）。 N50スコアが高くなるという見通しに基づく可能性がある実践から根本的に解決できないリピートを解決しようとする試みは、不正確なアセンブリにつながり、最終的に下流の科学的分析に影響を与える可能性がある。一方、見た目のあいまいさの点でアセンブリをブレイクする控えめなアプローチでは、最も長いコンティグを生成しない可能性がある。

　この意味では、最適なアセンブラは、すべてを識別して解決できるものでなければならない。同様に、この目的は、データが与えられた場合に可能な最大レベルのリピート分解能を有するアセンブリグラフの構成と見ることができる。ゲノムの完成したアセンブリが可能である場合、そのようなグラフは単一サイクル（単一の環状クロモソームの場合）からなるであろう。さもなければ、次の最良の目的は、長いrピートが単一のパスに崩壊する繰り返しグラフ（Pevzner and Tang 2001; Mulyukov and Pevzner 2002）の構築であろう。そのようなパスウェイは、標的ゲノムについての固有のあいまいさを捕捉し、データを考慮して解決することはできない。したがって、最大に分解されたアセンブリグラフを構築することは、繰り返し誘導された崩壊セグメントの数を最小化することに対応する。

　この作業の前提条件として、最初に、一連のリピートを考慮してどのリピートパターンを確実に解決できるかを理解する必要がある。この基本的な問題の初期の研究は、ハイブリダイゼーションによるシーケンシング（Ukkonen 1992; Pevzner 1995）に現れ、後にブリッジングの概念を通じたショットガンシーケンシングへと拡張された（Breslerら、2013）。リピートは、少なくとも1つのリードにそのコピーの1つが完全に含まれている場合にブリッジされていると言われる。ブリッジングの概念は、最大限に分解されたアセンブリグラフを、論文補足図S1で説明したように、非ブリッジリピートに対応するセグメントのみが折りたたまれたグラフとして定義できる。このようなグラフの新規構築は、可能な最も長いコンティグをもたらし、また標的ゲノムにおけるこれらのコンティグの妥当な配置を説明する。

　アセンブリグラフは、シーケンシングプロジェクトの初期段階からアセンブリパイプラインの重要な構成要素であった（Myers et al、2000）。アセンブリグラフ構築のアプローチは、通常、de BruijnグラフベースのアプローチとOLC（overlap-layout-consensus）アプローチの2つのカテゴリに分類される。 de Bruijnの枠組み（Pevzner and Tang 2001; Mulyukov and Pevzner 2002）では、すべてのk-merの集合がリードから抽出され、リードに連続して現れる2つのk-merがエッジ。この構造は、得られるグラフが本質的にオイラー（Aulerian）であり、k-bpよりも長いリピートが自然に単一のパスに崩壊するという望ましい特性を有する。さらに、典型的には、グラフの構成の後には、リピートをブリッジするリードを使用したリピート解決ステップが続く。これにより、いくつかのde Bruijnグラフベースのアセンブラは、未切断リピートのみが折りたたまれたままで最大限に分解されたアセンブリグラフを生成することができる（Pevzner and Tang 2001; Mulyukov and Pevzner 2002; Butler et al。2008; Peng他2010）。

　しかしながら、第3世代ロングリードシーケンシングの文脈において、標準的なBruijnグラフアプローチは、ショートリードシーケンスの場合と同様に成功していない。第3世代プラットフォームに関連するエラー率が高いため、多数の疑いのあるk-mersが作成され、de Bruijnグラフの構造が乱される。近年、限定された信頼性のあるk-mersの「近似」de Bruijnグラフを構築する方法として、solid k-mersの概念が提案されている（Lin et al、2016）。しかし、重複したリードは一握りの　solid k-merしか共有しないので、結果として生じるグラフはde Bruijnグラフの魅力的な特徴を欠く。特に、オイラー構造が損なわれ、リピートが適切に単一のパスに折りたたまれなくなった。一方、オーバーラップベースのアプローチは、オーバーラップに基づいたリードを、最初にk-mersに分解するのではなく、直接接続するため、リードエラーに対してより堅牢である。実際、最も利用可能なロングリードアセンブラ（Chin et al、2013、2016; Berlin et al、2015; Li 2016）は、いわゆるオーバーラップレイアウトコンセンサスパイプラインに基づいている。

　de Bruijnグラフはオイラー（Aulerian）グラフだが、オーバーラップグラフはハミルトニアンである。すなわち、ゲノム配列はグラフ中の各ノード（リード）を横切るサイクルに対応する。よく知られた計算上の課題（Nagarajan and Pop 2009）に加えて、ハミルトニアンパラダイムはリピートパターンの自然な表現を生成せず、グラフは一般的に不要なエッジで詰まっている。これらの問題に対処するために、もともとCeleraアセンブラ（Myers et al、2000; Myers 2016a）のためのストリンググラフアプローチ（Myers 1995、2005）が提案され、その後いくつかのアセンブリパイプラインによって採用された（Chin et al、2013、2016 ; Berlin et al、2015; Li 2016）。推移的減少手順を経て構築されたストリンググラフは、ゲノムの独特で非リペティティブな部分が単純な非分岐パスウェイに対応するオーバーラップグラフである。しかし、長いリピート（ブリッジと非ブリッジの両方）では、望ましくないグラフモチーフが生じることがある。実際には、ヒューリスティックのみがこれらのモチーフと戦うために使用され、最大限に解決されたオーバーラップグラフを構築することは困難である。

（以下略）

オーバービュー。GIthubより転載。

HINGEに関するツイート

インストール

付属のDockerfilesからイメージをビルドしてランしようとしたが途中でコケた。最終的にbiocontainerのイメージをpullして動作確認した。

依存

g++ 4.8
cmake 3.x
libhdf5
boost
Python 2.7

The following python packages are necessary:

numpy
ujson
configparser
colormap
easydev.tools
pbcore

git clone https://github.com/fxia22/HINGE.git
cd HINGE/
git submodule init
git submodule update
./utils/build.sh

#dockerイメージのビルド
git clone https://github.com/fxia22/HINGE.git 
cd HINGE/
cp docker/ubuntu14/Dockerfile .
#ビルド
docker build -t hinge .


#またはpublicのdockerイメージを使う (link)、ここではbiocontainersのイメージを使用
docker run --rm -itv $PWD:/data -w /data biocontainers/hinge:v0.5.0-4-deb_cv1

> hinge filter -h

$ hinge filter -h

undefined short option: -h

usage: Reads_filter [options] ...

options:

-b, --db db file name (string [=])

-l, --las las file name (string [=])

-p, --paf paf file name (string [=])

-c, --config configuration file name (string [=])

-f, --fasta fasta file name (string [=])

-x, --prefix prefix of (intermediate) output (string [=out])

-r, --restrictreads restrict to reads in the file (string [=])

-g, --log log folder name (string [=log])

--mlas multiple las files

--debug debug mode

-?, --help print this message

> hinge maximal -h

$ hinge maximal -h

undefined short option: -h

usage: get_maximal_reads [options] ...

options:

-b, --db db file name (string [=])

-l, --las las file name (string [=])

-p, --paf paf file name (string [=])

-c, --config configuration file name (string [=])

-f, --fasta fasta file name (string [=])

-x, --prefix prefix of (intermediate) output (string [=out])

-r, --restrictreads restrict to reads in the file (string [=])

-g, --log log folder name (string [=log])

--mlas multiple las files

--debug debug mode

-?, --help print this message

> hinge layout -h

$ hinge layout -h

undefined short option: -h

usage: hinging --prefix=string --out=string [options] ...

options:

-b, --db db file name (string [=])

-l, --las las file name (string [=])

-p, --paf paf file name (string [=])

-c, --config configuration file name (string [=])

-f, --fasta fasta file name (string [=])

-x, --prefix (intermediate output) input file prefix (string)

-o, --out final output file name (string)

-g, --log log folder name (string [=log])

--debug debug mode

--mlas multiple las files

-?, --help print this message

テストランについてはGithub参照。

実行方法

フラグでロングリードを指定するだけでハイブリッドアセンブリを実行できる。マニュアルより

# Run filter 
mkdir log 
hinge filter --db ecoli --las ecoli.las -x ecoli --config <path-to-nominal.ini> 

# Get maximal reads
hinge maximal --db ecoli --las ecoli.las -x ecoli --config <path-to-nominal.ini> 

# Run layout 
hinge layout --db ecoli --las ecoli.las -x ecoli --config <path-to-nominal.ini> -o ecoli 

# Run postprocessing 
hinge clip ecoli.edges.hinges ecoli.hinge.list <identifier-of-run> 

 # get draft assembly 
hinge draft-path <working directory> ecoli ecoli<identifier-of-run>.G2.graphml 
hinge draft --db ecoli --las ecoli.las --prefix ecoli --config <path-to-nominal.ini> --out ecoli.draft

# get consensus assembly 
hinge correct-head ecoli.draft.fasta ecoli.draft.pb.fasta draft_map.txt
fasta2DB draft ecoli.draft.pb.fasta 
HPC.daligner ecoli draft | zsh -v 

hinge consensus draft ecoli draft.ecoli.las ecoli.consensus.fasta <path-to-nominal.ini> 
hinge gfa <working directory> ecoli ecoli.consensus.fasta

#results should be in ecoli_consensus.gfa