[Canu Quick Start]
http://gembox.cbcb.umd.edu/mhap/raw/ecoli_p6_25x.filtered.fastq (233 MB)
이것을 가지고서 canu로 조립을 하면 하나의 contig가 나온다. 사용한 canu의 버전(canu --version)은 Canu snapshot v1.8 +484 changes이다.
>tig00000001 len=4639164 reads=9483 covStat=4029.14 gappedBases=no class=contig suggestRepeat=no suggestCircular=no
아쉽지만 circular 구조가 아닌 것으로 조립을 마무리하였다. 서열을 자체적으로 검색해 보아도 시작과 끝 부분에 overlap이 생기지 않는다.
그런데 어제 canu를 업데이트(git pull)하여 'Canu snapshot v1.8 +591 changes'로 만든 다음 똑같은 명령어를 실행해 보았다. 그랬더니 콘티그가 두 개가 생겼고, 그중 하나는 circular 형태임을 제시하였다. 길이도 이전 것보다 26 kb가 더 길다.
>tig00000001 len=4665388 reads=10601 class=contig suggestRepeat=no suggestCircular=yes
>tig00000002 len=18453 reads=13 class=contig suggestRepeat=no suggestCircular=no
오늘 다른 서버에서 canu를 업데이트한 뒤 전체 과정을 재현해 보았다. 결과는 같았다. 입력물은 동일한데 canu의 사소한 버전 차이로 인하여 contig를 circularize하느냐 아니면 못하느냐의 운명이 갈리는 것이다. 18 kb의 짧은 contig는 circlator를 통하여 염색체 속으로 병합되었다.
BLAST나 cross_match를 해 보면 두번째 canu에서 만들어진 contig의 앞과 뒤에서 20 kb가 넘는 overlap이 검출된다. 물론 두 영역이 염기서열 수준에서 100% 동일하지는 않다. 서열 검색 프로그램으로 명백한 overlap이 있지만 circlator는 이를 원형으로 만들어주지는 못해서 아쉬움이 남는다.
"악마는 디테일에 있다(The devil is in the detail)." Canu의 사소한 버전 차이가 이런 큰 차이를 만들어 내다니 정말 의외의 발견이었다.
2019년 11월 22일 업데이트
Canu의 신버전이 명백하게 24 kb가 넘는 겹침 영역을 contig 앞과 뒤에 만들었음에도 불구하고 circlator가 제대로 circularise를 하지 못한 이유는 무엇이었을까? 처음에는 데이터 분량이 충분치 않거나(25x), 겹치는 영역의 identity가 충분치 않아서 그런 것이 아닐까 하고 생각했었다. 그러나 blastn으로 계산한 percent identity는 무려 99.893%였다. Circlator의 실행 단계에서 match의 기준은 nucmer 기준으로 95%라서 identity가 충분치 않다는 것은 말이 되지 않는다. 왜 그렇지? Self correction을 더 해야 하나? pbalign과 quiver(arrow까지)를 이용한 교정을 실시했지만 여전히 circularize가 이루어지지 않았다.
왜 그럴까? Circlator 논문과 매뉴얼을 다시 읽기 시작하였다.
Corrected read를 쓰라고 떡하니 나와있지 않은가! 난 그동안 계속 원본 read를 쓰고 있었다. 난 바본가 보다. canu에서 교정한 데이터를 사용했더니 25x sample read로도 circularize가 정상적으로 이루어졌다. 150x sample data도 같은 결과를 얻었다.
Raw read를 추가하지 않는 상태에서 circlator minimus2로 circularization만 실시하는 시도에서는 여전히 실패다. 이것은 수수께끼로 남았다.
댓글 없음:
댓글 쓰기