Long-read 시대의 정렬 알고리즘

사실 아직 Long-read 시대라고 하기에는 전세계 적으로 생산되는 시퀀싱 데이터의 비율로 보면 꼬꼬마이긴 하나 그래도 비용이나 지금까지의 축적된 자료 활용이라는 몇몇 점들을 제외하면 짧은 애들시대는 조만간 저물지 않을까 합니다.

물론 짧은 애들 또한 계속 필요는 합니다. 그러나 Long read 이전과는 같지 않을 것이기에 Long read 시대를 준비해서 나쁘지는 않을겁니다.

그래서 "A survey of mapping algorithms in the long-reads era" 라는 논문 하나 준비해봤습니다.

DIO: 10.1186/s13059-023-02972-3

시대가 시대이고 영어 읽기 귀찮으니 구글에게 한번 맡겨보았습니다.

Q: 내 드라이브에서"s13059-023-02972-3.pdf" 파일을 읽고 자세히 한글로 요약해줘

서론:

DNA 염기서열 분석은 생명과학 분야의 핵심 기술이며, 롱리드 시퀀싱 기술의 발전은 이 분야에 큰 변화를 가져왔습니다. 롱리드 기술은 기존의 짧은 리드 시퀀싱 기술에 비해 훨씬 더 긴 염기서열 정보를 얻을 수 있지만, 이에 따라 데이터 분석 과정에서도 새로운 문제들이 발생했습니다. 그 중 하나가 롱리드 데이터를 참고 유전체에 매핑하는 과정입니다. 

본 논문에서는 롱리드 시대의 DNA 염기서열 분석에 사용되는 다양한 매핑 알고리즘에 대한 조사 연구 결과를 제시합니다.

1. 롱리드 기술 개요:

롱리드 기술은 10kb 이상의 긴 염기서열 정보를 얻을 수 있는 기술입니다.

롱리드 기술의 장점은 다음과 같습니다.

• 유전체 구조 변형 (SV) 분석에 유리
• 단일 분자 haplotyping 가능
• 염기서열 조립 (assembly) 과정 개선

롱리드 기술의 단점은 다음과 같습니다.

• 높은 오류율
• 높은 컴퓨팅 비용

2. 매핑 알고리즘 종류:

롱리드 매핑 알고리즘은 크게 씨앗-확장 (seed-and-extend) 프레임워크와 씨앗-체인 (seed-and-chain) 프레임워크로 나눌 수 있습니다.

씨앗-확장 프레임워크는 짧은 리드 매핑 알고리즘에서 사용되는 기본적인 방법입니다.

씨앗-체인 프레임워크는 롱리드 데이터의 특징을 고려하여 개발된 새로운 방법입니다.

3. 주요 매핑 알고리즘 비교 분석:

본 논문에서는 다음과 같은 주요 매핑 알고리즘을 비교 분석했습니다.

• Minimap2
• NGMLR
• GraphMap
• LSC
• BWA-MEM
• LAST
• BLASR
• RapMap
• SMALT

비교 분석 기준은 다음과 같습니다.

• 정확도
• 속도
• 메모리 사용량
• 특징

4. 매핑 알고리즘 선택 가이드:

연구 목적에 따라 적절한 매핑 알고리즘을 선택해야 합니다.

정확도가 가장 중요한 경우 Minimap2 또는 NGMLR을 사용하는 것이 좋습니다.

속도가 가장 중요한 경우 LSC 또는 BWA-MEM을 사용하는 것이 좋습니다.

메모리 사용량이 가장 중요한 경우 GraphMap 또는 LAST를 사용하는 것이 좋습니다.

5. 향후 연구 방향:

• 롱리드 기술 발전에 따라 새로운 매핑 알고리즘 개발
• 멀티 샘플 데이터 분석을 위한 효율적인 알고리즘 개발
• 염기서열 변형 (variant) 분석을 위한 정확한 알고리즘 개발

결론:

본 논문은 롱리드 시대의 DNA 염기서열 분석에 사용되는 다양한 매핑 알고리즘에 대한 종합적인 개요를 제공합니다. 각 알고리즘의 특징, 장단점, 성능 비교 등을 분석하여 연구 목적에 맞는 최적의 알고리즘 선택에 도움을 줍니다.

추가 정보:

• 롱리드 시퀀싱 기술: https://www.vogue.com/article/hairstyles-for-long-hair
• DNA 염기서열 분석: http://www.incodom.kr/%EC%97%BC%EA%B8%B0%EC%84%9C%EC%97%B4

오... 비약도 있고 생략도 많지만 (물론 클로드 3에 비해서는 아직 갈길이 멀듯합니다)그래도 pdf파일을 요약해줍니다. 근데.. 추가 정보에 롱리드 시퀀싱 기술의 url이..  신박한 링크를 넣어놨네요;; Orz

출처: @ye._.vely618

Long Read Sequencing을 전적으로 믿으셔야 합니다.

항상 느끼는것이지만 사람들은 익숙한것에 익숙하다는...
물론 이 글을 쓰는 본인도 별반 차이 없다는게 현실
그럼에도 불구하고 세상에는 익숙한것을 거부하고 한 걸음 나아가는 분들이 있어서 발전한다는...

오늘은 유전체분야에서 다들 익숙한 짧은길이의 시퀀싱 플랫폼 대신 Long read 시퀀싱 플랫폼을 왜 써야하는지 보여주는 논문이 있어 들고와봤습니다.

The blooming of long-read sequencing reforms biomedical research

DOI: 10.1186/s13059-022-02604-2


Long read 시퀀싱의 대표주자인 PacBio와 Nanopore가 나온지도 꽤 된것 같으나, 아직 주류 시퀀싱 플랫폼으로서는 자리매김을 하지 못한... 조명받지 못하고 있지만.. 그 진가를 하나둘씩 알게되고 안쓸수 없지 않을까 합니다.

물론 이 Long read 플랫폼을 안 쓸수 없지만 PacBio/Nanopore 플랫폼을 이용해서 진단 키트를 개발하여 돈을 벌 수 있게 된다는 것은 아닙니다. 오해 없으시기 바랍니다. Long read 플랫폼에서 기존 NGS 시스템에서 해온 것 같이 하려고 하면 개인적인 생각으로는 그냥 하지 마세요 라고 말하고 싶네요. 그런 생각이라면..

여튼 Long read 플랫폼은 genome assembly과 transcriptome 분야에서 활약을 하고 있다고 하는데 이는 기존 NGS의 짧은 read로 인한 한계를 극복하였기 때문에 가능한 당연한 결과였을 듯 합니다.

genome assembly를 설명하면서 이런 저런 설명을 하였는데 사실 T2T genome이 세상에 나왔는데 무슨 설명이 더 필요할지... 물론 다배체면서, repeat 서열이 엄청 긴 식물과 같은 다양한 생물의 유전체 연구에서는 아직 할일이 많이 남아있을듯 합니다.

그리고 더불어 transcriptome, 전사체에서도 두각을 나타내고 있다고 합니다. 이전에 PcaBio사에서 나온 Iso-Seq이라는 플랫폼이 있었는데 기존 숏리드 플랫폼으로는 할 수 없었던 full-length 유전자 서열을 확인하여, 다양한 gene의 isoform 을 확인 할 수 있었는데, 이제는 이는 당연한것이고, read count를 활용하여 정확한 발현 측정까지도.. 가능하다고 합니다. 또한 이 논문에서 처음 보았는데 exitron이라는 것도 확인하였다고 하네요.

더불어 당연히 암연구에서도 long-read 플랫폼이 중요한 역할을 하고 있는데, 시퀀싱을 위해 dna나 rna가닥을 증폭시키지 않은 특징 때문에 가능 응용법이긴하죠. 특히 nanopre 플랫폼을 사용하여 급성 골수성 백혈병 (AML) 환자의 RNA변이와 fusion gene 구조를 확인하기도 하였고, 대장암 세포주에서 5mC 위치와 양을 정량하여 각각 AML와 대장암 연구에 도움이 되고 있다고 합니다.

이렇듯 Long Read Seq 플랫폼은 이제 쓰지 않을 이유가 없는 플랫폼으로 우리 곁에 생각보다 가깝게 다가왔으나 생각에는 Long이든 Short든 정확하게 내 병의 이유를 빠르고 "싸게" 알아낼 수 있으면 모두 행복한 것 아니겠습니까?

그럴 수 있는 방법이 어딘가에 있겠죠, 없으면, 언제나 그러했듯이 우리는 또 해답을 찾아내겠죠. :)

출처: @ye._.vely618

롱리드 시퀀싱을 쓰지 않을 이유가 있는가?

이번 논문은 제가 참여한 논문입니다.. 흠흠..

이름하여 Two long read-based genome assembly and annotation of polyploidy woody plants, Hibiscus syriacus L. using PacBio and Nanopore platforms

DOI: 10.1038/s41597-023-02631-z

Hibiscus syriacus, 쉽게말해 무궁화 genome을 assembly하는데 어떤 데이터를 어떤 assembly 도구로하면 그래도 가성비가 좋은지에 대해서 확인한 논문 되겠습니다.

무궁화는 full genome은 이미 몇해전에 나와있는 상태고요, 아마 무궁화가 2배체가 아니라 4,6배체로 기억됩니다. 그래서 숏리드가지고 assembly가 만만치 않았는데 그 데이터를 바탕으로 이전에는 short리드로 어렵싸리 했었는데 이번에는 롱리드 시퀀싱으로 하면 어떻게 되는지 확인 해보자 입니다.

이전 무궁화 genome project 논문에서 핸들링하는 데이터 양을 정확히는 모르겠으나 어마무시했던것으로 알고 있습니다. 거기다가 숏리드라서 양쪽 로우 퀄리티 좀 정리해주고, scaffold용 mate-paired 데이터 정리작업하는데도 아마 꽤나 시간이 걸릴겁니다.

나노포어 데이터(ONT)와 PacBio data가 있었는데, 솔까말 ONT 데이터로만 해도... 사실 갠춘합니다.

그런데 여기서 중요한것은 ONT가 중요하기도 하지만 ONT의 장점을 십분 발휘할 수 있게 해주는 DNA 뽑는게 ART되겠습니다. ONT가 길게 읽을 수 있는거지 template가 짧으면 ONT도 길게 읽고 싶어도 못읽습니다.

결국 실험자의 손이 중요합니다. 손 똥손이면 ONT도 해결 못해줍니다.

그 똥손도 가능하게 해주는게 commercial prep kit이긴한데 현재 기준으로 그런 kit이 있는지는 저는 모르겠습니다. 

여튼 그래서 ONT 데이터를 앞뒤없이 다 때려박고 assembly하지 않았습니다.

cell 하나, cell 2개, 결과가 어떻게 달라지는지 확인해고, assembly tool마다 결과는 어떻게 나오는지 확인하면서 테스트 하였고, 이거쓰세요는 하지 못했지만 그럭적럭 요정도 생산해서 이 tool쓰면 평타 칩니다 라고 가이드는 해드릴 수 있는 논문되겠습니다.

다음에는 테스트하는 code를 간지나게 git에 올려놓고 논문에 url하나 올려둘 수 있도록 해봐야겠습니다. :)

그럼 또 쓸만한 논문을 찾아 돌아오도록 하겠습니다.

출처: @ye._.vely618

Omniome 넌 누구냐

광고?뉴스?기사?글이 하나 포착되어 보는데

Pacific Biosciences signs a definitive agreement to acquire Omniome

Omniome이라는 처음보는 회사가 보여서 잠깐 검색 하는데 캐서린 우드의 ARK가 여기서 나오네.. ㄷㄷㄷ

여하튼 PacBio의 Long Read와 Omniome의 (길이는 언급하지 않겠다) 정확도가 만나 일루미나의 SBS(sequencing-by-synthesis)대항하여 SBB(sequencing-by-binding)라는 기술로 PacBio랑 잘 해보겠다? 정도인듯한데..

SBB가 무엇인지 한번 찾아보는것에 의의를 두도록 하겠습니다.

Omniome에서 SBB에 대한 논문과 특허는 이미 등록되었고 논문은 요기에 특허는 요기에 등록되어 있어보이고...

아.. 일단 갱장히 본인들을 잘 설명해놓았다고 생각하겠지만.. (아니면 본인들도 어떻게 설명해야 할지 잘 모르고 있다는것에 한표.. 이과놈들이란...)

여튼.. 한개 base를 읽기 위해 4개의 염기가 모두 필요하고..
올바른 base면 감지 가능한 신호(복합체)가 생기고...

이거... 복합체와 센서를 이온으로 변경하면 Ion Proton이랑 좀 비슷한듯....

여튼 SBB기술을 이해하려고 내가 알고있는 기술로 단순화하해서 접근해보니.. ion proton이랑 비슷한듯하네요..

처음에 미지의 서열에 A,C,G,T가 binding하고 이 서열이 올바른지 아닌지는 binding하여 만들어진 복합체의 양?에 따라 올바른 서열인지 아닌지 확인하는.. 모 그런 기술로 보여지는데..

추후에 더 이 기술에 알게 되면...
물론 나는 SBS, SBB같은 SRS(Short Read Sequencing이라고하는..)들은 별로 관심안가지지 않을까하는 생각이....

근데 ARK 실망..... 관심있어하는게 PacBio와 Omniome이라니.. 

옥스포드의 나노포어가 있는데....

출처: @ye._.vely618

Long read는 Long read alignment로....

간만에 글 투척합니다.

오늘은 Long read align관련된 내용 투척 하도록 하겠습니다.

시퀀싱 기술이 좋아져서 PacBio와 함께 nanopore가 (최근 covid도 있었고) 함께 많이 이용되고 있는데 질좋은 long read를 생산하셨다면 bwa/bowtie와 같은 short read alignment보다는 long read에 최적화된 long read alignment인 minimap2같은 tool를 사용하시는게 정신건강에 좋을 것 같습니다.

최근 제가 별생각없이 long read서열을 human genome에 aling할때 bwa mem의 -x ont2d옵션을 사용하여 진행했었는데...

통수를 후려 갈기는... (원래 통수는 후려 갈기는 맛이 좋다능)

bwa mem -x ont2d를 사용하는 경우 원래 생산된 read(raw read 개수)보다 더 많은 read 들이 aligned되는 것 처럼 보인다는... (?? 생산된게 100개 read인데 align된 read는 200개라고?)

근데 minimap2를 사용하였을 때에는 reference에 align된 read의 개수와 생산된 read 개수(raw 리드 개수)가 유사한(aka 생산된 read 개수보다 적은) read 개수를 확인 할 수 있었습니다.

개발자도 같고(Heng Li), 같은 align하는 tool인데 왜 이렇게 차이가 나느냐 

음... bwa와 minimap2를 자세히 까보지는 않았지만(못하지만) bwa의 경우 mem -x ont2d를 사용한다고 하더라도 태생부터가 short read를 위해서 만들어진 alginment이고 nanopore의 경우 마음먹고 시퀀싱이 된다면 수십 kb의 길이가 나오는 관계로 bwa mem에서 seed를 기준으로  align할때 mismatch나 error에 대해서 관대하게 조건을 잡으면서 확장을 한다로 하더라도 수십 kb까지 확장하지 못하는 경우가 발생 하고 그 경우 split이 되어 다른 reference에 align되는 경우가 발생하는것으로 보였습니다.

대신 minimap2의 경우 long read를 고려해서 만들다 보니 확장이 비상식적으로 read가 길더라도 확장을 하지 split하지 않아서 bwa의 경우와 같이 생산된 read보다 많은 read가 align된 것 처럼 보이는 이상한 문제는 발생하지 않는 것 처럼 보였습니다.

결론은 내 데이터에 맞는 mapper를 사용해서 분석하자 되겠습니다. ㅠ.ㅜ

추신: 2018년도 이런 글(Minimap2 and the future of BWA)도 있었군요;; 

출처: @ye._.vely618

PacBio Sequel System

Sequel에 대한 자세한 내용은 Here 를 보시면 더 자세히
알수 있을 것이고...

2017년 3월 8일 기준 어제인 3월 7일 K호텔에서 PacBio 워크샵이 있었는데
Sequel 출시 이후 다양한 업그레이들이 진행되고 있었네요..

그리고 국내에 Sequel이 3?대인지는 모르겠으나 3개의 site에는 들어와서
데이터가 생산되고 있다능..

여튼 기존에 150만개 hole에서 생산되던걸 1천만개 hole에서 생산해서
생산량이 좀 되서 multiplexing이 된다는게 엄청나진 않지만 나름 진일보..

RSII는 생산량이 적은 관계로 multiplexing의 필요와 이유도 없었는데
Sequel은 RSII 6-7Cell을 한번에 돌리는거니깐 multiplexing이 필요해진듯
근데 multiplexing에 이용되는 barcode가 384개라는게 (Barcode 관련 웹페이지) ㅋ
모 종류가 384개지 이걸 꼭 다 써야하는건 아니니... 혹시 몰라서 여분의 barcode를... (여분이 좀 많은게.. ㅎㅎ)

저는 휴알못인 관계로 Non にんげん 기준으로 Sequel 장점은 3가지정도..

- de novo Bacteria는 Sequel에 5개 pooling해서 시퀀싱해도 나름 괜찮은 결과가 나올듯  물론 RSII 1 Cell과 Sequel 1 Cell과 가격을 비교해봐야겠지만..

- 곰팡이는 1 Cell만 돌려도 de novo하기에 충분한 output이 나오게된 상황 (대신 라이브러리를 2-3개 만들어서 pooling해서 sequencing). 가격을 봐야겠지만 곰팡이 community는 충분한 매리트가 생긴듯...

- Iso-seq은 RSII는 최소 3개 cell 가지고 시퀀싱써야했는데 이제 multiplexing되니깐 3종류 만들어서 Sequel 1 Cell에 넣어버리면 OK 된듯.. 3반복하려면 단지 3개 셀!! (이라고 쓰고 라이브러리는 3개 아닙니다 고갱님 ㅋ)

여튼 NovaSeq과 MinION이 계속 PacBio의 똥꾸멍을 찔러대고
투자자는 돈 회수하고 있어도 기술적으로 봤을때는
아직까지는 쓸만한...

그리고 현 시점에서 대한민국에 국한되어있지만
PacBio 인기가 시들하다고 할 수 있을까...
PacBio 시퀀싱 의뢰하면 지금이 3월 8일인데 4월 중순이후에야 raw data를 받을 수 있는 현실!!!

대규모 과제에서 PacBio sequencing 요청이나
누군가 휴먼급 genome을 RSII Only로 de novo을 하거나...
아님 둘 모두...

아놔 좀 큰놈들은 Sequel 쓰라고 Sequel 만들었는데 왜 RSII 쓰냐고 ㅋ

HGAP parameter 비교 결과

우선 PacBio에서 사용되는 용어에 대해서
잘 정리된 문서가 있어 링크 합니다.
>PacBio Term<

작년 말에 PacBio SMRT portal 에서 HGAPv2와 HGAPv3비교를 해보려고 했는데 해보신분은 아시다싶이 HGAPv2의 **맞은 속도로인해 HGAPv2의 parameter 비교는 skip하고 HGAPv3를 기준으로 parameter마다 bacteria genome이 어떤 변화가 있는지 비교해보았습니다.

-그렇다고 제가 HGAPv3를 사용한다는것은 아니라는 점! ;)

HGAPv3은 기존의 다른 de novo assembly 프로그램과 유사하게 Filtering/ Assembly/ Mapping/ Consensus 단계를 거쳐 진행합니다.
대게 de novo assembly 메뉴얼 작업을 하신 분들의 경우 filtering/trimming하고 assembly 무한 반복? 하고 mapping해서 insert size대로 mapping이 되는지 확인을 해보셨을 겁니다. ㅎㅎ
근데 PacBio Portal에서 스스로 잘 해줍니다. @.@

다음은 step마다 있는 parameter와 값들을 한번 정리 해봤습니다.

Step	Protocol	Parameter	Value
Filtering	PreAssemblerSFilter.1.xml	Min. Subread Length	500
		Min. Polymerase Read Quality	0.8
		Min. Polymerase Read Length	100
Control Filtering	KeepControlReads.1.xml	None	None
Assembly	AssembleUnitig.1.xml	Genome Size	5000000
		Target Coverage	25
		Overlapper Error Rate	0.06
		Overlapper Min Length	40
		Overlapper K-Mer	14
	PreAssemblerHGA.3.xml	Min. Seed Read Length	6000
		Num. of Seed Read Chunks	6
		Alignment Candidates Per Chunk	10
		Total Alignment Candidates	24
		BLASR Options	-noSplitSubreads -minReadLength 200 -maxScore -1000 -maxLCPLength 16
		Min Coverage For Correction	6
Mapping	BLASR_Resequencing.1.xml	Max. Divergence	30
		Min. Anchor Size	12
Consensus	AssemblyPolishing.1.xml	None	None

위의 옵션들 중에서 제가 직접 조정해본 parameter들은 Filtering단계인 Min Subread Length, Min Polymerase Read Quality,  Min Polymerase Read Length, Assembly단계중 AssebleUnitig단계인 Genome Size, Target Coverage, 그리고 같은 Assembly단계인 PreAssemblerHGA단계의 Min. Seed Read Length정도를 고려해봤습니다. 건드린 옵션 이름보시면 매뉴얼 de novo assembly해보신 분들이라면 예상 가능하시리라 봅니다.
-음.. 가끔 이런 거 보다 더 잘 정리해서 논문으로 출판되는 경우가 있긴하지만....

그리고 추가적으로 더 손대면 결과가 좋아질 수 있을만한 옵션들이 있겠지만 시간관계상 (제가 주구장창 이것만 돌릴 수 있는 처지는 아닌지라... 모 여러 조건의 샘플과 무한한 서버를 제공해주신다면 테스트는 해드릴 수 있습니다. ;) )

여튼 결과부터 말씀드리자면 조건 변경(aka 최적화)해서 결과 얻으면 좀더 좋아질거 같죠?
시간낭비하지 마셈 되겠습니다. >_<

너님 나랑 장난하냐? 너 이자식 지금 결과보여주기 귀찮아서(이건 부정 못하겠네요ㅋ) 주작질 하는거지? 하실 수도 있는데 제가 테스트한 기준이 보통 bacteria genome을 진행하는데 사용되는 1 Cell 이라서 그런 탓도 있겠지만 알고있던 정보와 실제 나온결과와 10%이상 차이 안 나면 옵션 암만 최적화 해봤자 그 나물의 그 밥입니다.

그리고 옵션마다 값을 조절하면 그에 따라 그 다음 스텝의 input이 바뀌어 영향을 받지만 한정된 데이터에서 옵션값 조절해서 데이터의 결과가 다이내믹하게 바뀐다면 그건 최적화를 잘한 것이 아니라 시퀀싱데이터가 이상할거라는 느낌적인 느낌이 드시죠?

Filtering단계에서 read길이 올리고, 줄이고, 조금 떨어지는 데이터를 확보한다는 계획으로 read quality를 낮추더라도 어차피 서로 계속 영향을 줘서 default parameter로  생성된 데이터와 큰 차이 안 납니다.

결론: 1 contig 안 나오고 circluar형성 안되는 애들은 parameter 최적화 해봤자 안됩니다. 스트레스 받지말고 추가 시퀀싱하세요. 

샘플 좋고 시퀀싱 잘되면 분석툴이 개 이상하지 않으면 reasonable한 결과 나옵니다. :) 
default 의외로 성능 괜찮습니다. 내가 연구하는 건 나처럼 변태스러운 녀석이야! 하지 않는 이상 default쓰시면 평타는 칩니다. 

ps. 믿거나 말거나 조건 변경하면서 20번정도 테스트 해봤습니다. PacBio에서 제시하는 것 중에 추천하는 Genome Size 옵션이 영향을 많이 줄 수 있습니다. Genome Size를 기준으로 데이터를 정리하기 때문에 그런 것 같습니다. 그리고 Target Coverage는 bacteria의 경우 1 cell만 해도 대중 100x가 나오는데 target coverage (15-30) 조절해봤자 의미 없는 것 같습니다. bacteria말고 다른 종들은 의미가 있을지도...

HGAP 버전 비교

PacBio에서 assembly를 담당하고 있는 HGAP과 Falcon을 주로 사용하고 있는것으로 알고 있는데 오늘 그 중에서 HGAP을 잠시 확인 하도록 하겠습니다.
왜 HGAP만 확인하느냐?
제가 HGAP을 많이 쓸 예정이거든요 ㅋ
Falcon궁금하시면 직접 하시면됩니다!! :)

우선 HGAP 버전을 한번 살펴보겠습니다.

HGAP버전을 보시면 3개가 존재합니다. 그러나 HGAPv1의 경우 이미 이번 SMRT버전에서 퇴출당했습니다. 당시에는 long read로 어셈블리해서 획기적으로 계산량을 줄이긴 했으나 Celera Assembler 자체가 시간이 많이 걸리기 때문에  (CA자체라기 보다는 특정 모듈들이겠죠?) 자체 프로그램을 고안해서 HGAPv2외에 추가로 HGAPv3까지 내놓은 상황입니다.

근데 보통 New버전 나오면 예전거 갈아치우는데(한국이 그런 경향이 많긴하지만.. 모 특정 위치에 있는 분들은 상당히 잘 안바뀌긴하죠..) HGAPv2와 HGAPv3를 계속 사용하고 있습니다. 두개의 큰차이는 consensus 부분인데 이것에 따라 속도와 결과물 차이가 나기때문에 두개 결과중에 좋은거 사용해라하는 느낌이 있습니다.

그래서 현재 HGAPv2와 HGAPv3에 대해서 테스트를 계획중이고
각 단계별로 parameter를 바꿔주면 어떻게 바뀌는지 비교해볼 계획입니다.
PacBio를 사용하시는 업자분들께서는 어떤 버전을 최적화해서 사용하는지는 잘 모르겠으나 아마 각각의 장단점이 있을겁니다. 그래서 직접 테스트를 해보겠다능~ :)

그럼 HGAP 비교글은 내년에 좀 더 볼만한 내용을 찾아뵙도록 하겠습니다. :)

16S rRNA와 시퀀싱플랫폼

블로그에 쓰는 내용이 16S rRNA에 많이 집중되고 있긴하죠? ㅎㅎ
하는일이 이거다보니.. :)

여튼 오늘은 16S rRNA와 시퀀싱플랫폼에 대해서 잠시 이야기 하도록 하겠습니다.

최근 16S rRNA sequencing의 최강자 454가 서비스를 bye bye한 관계로
많은 연구자들이 MiSeq체제로 변환하고 있는데 (물론 Ion도 있고, PacBio도 있습니다.)
기존에 454를 사용했을 때와 다른 V region을 사용하고 다소 다른 결과들을 보이는 것들이
있을 것 입니다. 그래서 이리저리 검색하다가 걸린 논문 두 개를 가지고 잠시 얘기해보고자 합니다.

Nucl. Acids Res. (2010) 38 (22): e200.

PeerJ (2016) 4:e1869

논문을 찾아보기 시작한 이유는 454가 막을 내린 후 다른 시퀀싱 플랫폼에서는 왜 다른 region을 target하고 있고 왜 diversity에 차이를 보이는지... (내가 분석을 잘못했나.. ㅎㄷㄷㄷ)

우선 V region, 454는 V1-V2였는데 MiSeq은 V4 region을, Ion은 4개 region? 7개 region? 을 동시에target하고 있다는..

모 논문보면 아시겠지만
2010년 논문은 454 vs MiSeq을 비교했습니다. 두 플랫폼이 차이가 날까? 어떤것이 차이가 날까?

2010년도 논문을 한장 figure 요약하자면 이거죠

상단은 phylum abundance/ 하단은 genus abundance 그리고 좌측에 있는 V4는 이전 연구에서 사용되었던 기준이라고 생각되는 참고용 분포입니다. 실험 결과가 V4 region이 저 분포를 나타내면 실험이 잘됐다고 확인하는 용도로 사용됩니다.

사실 phylum은 크게 차이없죠, 차이가 있기도 쉽지않습니다.
관심사는 genus되겠습니다. 일루미나 데이터의 대부분은 unclassified입니다. 논문에서는 error때문에 이렇게 나왔으니 error좀 낮아지면 일루미나가 output이 많으니 sequence error 문제점을 개선된다면 미생물 분석에 적합한 킹왕짱 시퀀서가 될거라고 하는데 개인적인 생각으로는 sequence error(454가 일루미나가 한테 sequence error ㅋㅋ 좀 웃겼다능..
systematic error는 눈에 안뵈냐라고 한다면 눼눼, 하긴 이 논문이 2010년이란 것을 감안한다면 무리는 아니긴 합니다.)보다는 db선택이 unclassified문제는 보정할 수 있지 않을까 합니다.

그렇다면 이제 16s rRNA 입문한지 얼마안된 님께서 그렇게 느끼는 느낌적인 이유는
무엇인가?

바로 2016년 논문되겠습니다.

2016년 논문은 PacBio로 시퀀싱한 것을 db에 따라 분석 결과가 달라지는냐에 대한 내용으로
다음 한 장으로 요약 할 수 있겠습니다.




동일한 시료를 가지고 시퀀싱한 데이터를 16S rRNA db에 따라 classification되는 정도를 확인해본 그래프 입니다. 느낌 딹오시죠?
다만 나중에 뒤통수 맞았다는 느낌 안 받게 하나 말씀드리자면 RDP와 Silva의 경우 genus까지만 확인했고 gg는 genus와 genus+species 두가지로 확인한 것 입니다.

이제 PacBio의 Sequel에서 CCS로 생산된 16S rRNA 서열가지고 연구해도 나쁘지 않을 것 같다는..

아.. 이제 돈만 많으면 되는건가!!! 

Long-read sequence assembly of the gorilla genome

서부저지고릴라(Western Lowland Gorilla, Gorilla gorilla gorilla) 중 하나인 Susie의 genome이 PacBio를 이용해서 좀더 high resolution으로 만들어졌다는 아름다운 논문입니다.

Long-read sequence assembly of the gorilla genome

왼쪽 녹색은 Susie, 오른쪽 아이보리색은 gorGor3의 contig size

각각 전체 Genome에서 10% 서열을 나타내는데 사용되는 contig 개수를 보여주는 그림으로 PacBio로 시퀀싱하여 어셈블리한 Susie가 short read assembly로 하는것보다 월등함을 확인시켜주고 있다(300M를 보여주는데 susie는 contig개수가 10개 남짓이면 되는것에 비해 gorGor3는 세어보시길;;;).

그리고 첫장 Table1에서 기존에 short read assembly한 결과보다 이번 결과가 더 월등하다는것을 여실히 보여주고 있는데 스캣폴드 개수가 554개 무슨 곰팡이 contig 개수인줄..
contig 최대 길이 서열은 36M bp, scaffold 최대 길이 서열은 110M bp. orz

그밖에 논문에서
기존 genome에서보다 gap 더 줄였구요
기존에 짧게밖에 못봤던 mobile element들 거의 full length로 확인할수있었구요
수kb에 달하는 insertion 확인해서 유전자 없는것도 확인할수 있었습니다라는
다양한 잘난척을 시전해 주고 계시는데...


결국 사용한 SMRT cell이 236개라는...
이거 PacBio 시퀀싱가격만... ㄷㄷㄷㄷ

이 논문보시고 우리도 genome 향상시킬수있어!! 라고 핑크빛 바램을 가지고 있으시는분들..  여러분들도 원래부터 좋은 genome가지고 연구할수 있었습니다.
다만 연구비가 귀여워서 못한것 뿐이고 그리고 모든 동물에 대해서 이렇게
드라마틱하게 genome 품질이 향상되지는 않습니다.
척추동물정도면 이정도 연구비 때려부으면 가능하지만 그 이하에서는 아직
해결해야할 것들이 좀 있습니다.

다 아시는 분들께서 모르시는척 하시기는... :)

그리고 PacBio의 Sequel 출시로 기존에 RSII로 했을때 보다는 반값에 가능하지 않을까합니다.
일단 SMRT cell개수를 줄일수 있으니... ㅋㅋ
그거 노리고 일단 RSII기준으로 시퀀싱비용 비싼듯보이게하고 Sequel로 하면 싼것처럼 느끼게 하려는 고도의 노림수인가;;;

여튼... 잘 따져보시고 시퀀싱하시기 바랍니다.

너도나도 앞다투어 시퀀싱하면 거지꼴 못면합니다.

Widespread Polycistronic Transcripts in Fungi Revealed by Single-Molecule mRNA Sequencing

Widespread Polycistronic Transcripts in Fungi Revealed by Single-Molecule mRNA Sequencing

간만에 읽은 저널 한편...
어느 지구정복을 꿈꾸시는 과학자분께서 운영하시는 것에 비하면 그냥 트윗터 수준임을
미리 알려드립니다.

자세히 안파해칩니다.

필요한것만 읽습니다.(제목만 보고 대충 때려맞추겠다는 심본데? 정답!!)

곰팡이중 basidiomycete fungi를 Iso-Seq을 이용하여 transcriptome 분석을 수행하였고, 우리는 기존의 short read가지고 깨작대던 님들이 못찾는거 찾는 기승전시퀀싱자랑하는 논문되겠습니다.

일단 이 논문은 JGI와 Pac이 손잡고 만들었습니다.
이 말은 곧 SMRT 비용 신경안쓰고(는 아니고 다른 연구자들보다 적게 신경썪을..) 분석에 사용하기 좋은 고 퀄러티 read들을 넉넉히 생산했을 것이기에 이런거 하고 싶다고 그냥 무작정 논문에 나온 SMRT cell 만큼 시퀀싱하시면 거지꼴 못면합니다.
suppl보시면 아시겠지만 SMRT cell 두자릿수 입니다. 앞자리가 10이 아닌건 안비밀 Orz..

복잡하고 어려운거 직접 보시면되니깐 쉬운거 말씀드리고 끝내겠습니다.

기존에 분석한 basidiomycete fungi중 Plicaturopsis crispa를 집중으로 파해쳤는데 이전까지 알고 있는 isoform 비율 10%가 아닌 한 20%정도 된다. 그리고 곰팡이도 isoform 3개 이상짜리도 엄청 많이 있음. 우리 곰팡이 무시하지 마셈.

그리고 비교셋으로 일루미나 숏-리드도 시퀀싱해서 ToFU (Transcript isOforms: Full-length and Unassemble,의 약자로 iso-seq을 분석하는 파이프라인? 시퀀싱 전략? iso-seq 결과물? 논문 보시면 아시겠지만 다양하게 사용되는것을 알수 있음)와 비교해봤는데
기승전 풉 짧은 것들은 안됨.
(하..... 지금까지 짧은것가지고 한것도 서러운데.....  ㅠ.ㅜㅋ)

여튼.. 모 검증은 해봐야하는거고 이 논문에는 RT-PCR해서 polycistronic 검증을 하긴했는데 좀더 확인해봐야 할것 같고..
새로운것 찾았다고 하고싶은 분들은 Iso-Seq 관심가지고 해보시는것도 나쁘지 않을것 같습니다.

근데 왜 너는 PacBio 관계자도 아니면서 PacBio로 실험한 논문 소개 하냐?

제 비록 제가 몸담고 있는 곳에는 PacBio가 주력이 아니지만
저는 언제나 연구자분들이 좀더 멋진 연구를 하실수 있도록 아낌없이
조언을 해드리고자 고심하는 연구자아니깐요 (캬~ 멋있다)

파일의 포맷을 변환하는데 필요한 것들

내가 아니란 말이닷!!! ㅋㅋ

python에서 Biopython을 이용하여
간단하게 convert하는 샘플 코드를 제공하고 있으니
여러분들도 쉽게 만들수 있어요~ :)
Biopython에서 제공하는 Tutorial 


오늘 문의가 들어온 파일은 sff파일
Roche의 454 GS FLX? sequencing 결과파일로....
ABI와 함께 illumina한테 밀려서 뒷방으로 들어앉은 파일 포맷입니다.
그러나 아직도 쓰는 이유는 read 길이가 길기때문 :)

그렇습니다. PacBio도 Nanopore다 디립다 길게 sequencing해준다는
애들이 있습니다. 그런데 왜 옛날꺼 쓰냐?? PacBio는 base quality가 안습이고,
Nanopore는.... 언제 출시일지 전 잘 모르겠습니다. 업자가 아닌관계로 ㅎㅎ

그래서 위의 길게 sequencing 해준다는 시퀀서를 제외하고는 Roche의 454가 read 길이가 가장 길다고 할 수 있겠습니다. NGS중에선 말이죠

그런데 sff파일을 보려고 하면 문제가 생깁니다.
권모씨께서 문의를 한것이 그것때문인지는 모르겠지만 걍 일반인이
sff파일을 걍 직접 볼수가 없습니다. 왜냐 binary파일이니깐요(sff파일이 binary라고
알고 있는데  직접 다뤄본적이 없어서... ㅎㅎ )

그래서 사람이 볼수 있게 파일을 변환시켜줘야 한다는 겁니다.

convertSff.py

#!/usr/bin/python

import os, sys
from Bio import SeqIO

try:
inputSFF = sys.argv[1]
outputPREFIX = sys.argv[2]

except:
print "Usage: python convertSFF <input.sff> <output_name>"
print ""
exit(1)


SeqIO.convert(inputSFF,"sff","%s.fasta"%(outputPREFIX), "fasta")
SeqIO.convert(inputSFF,"sff","%s.quality"%(outputPREFIX), "qual")
SeqIO.convert(inputSFF,"sff","%s.fastq"%(outputPREFIX), "fastq")

권모씨의 요청으로 급조한 날림 convert python 코드 ㅋㅋ
이 스크립트를 수행하면 세개의 파일이 나오게 될것으로 예상됩니다. ㅎㅎ
안나오면 어쩔수없고... ㅎㅎ


아.. 그리고 사족으로 LT사의 SOLiD의 경우 우리가 알고 있는 서열과 달리
첫 염기 서열만 서열이고 그 다음부터는 A/G/T/C 알파벳이 아닌 숫자로 되어있는데..
이걸 굳이 변환해서 reference geneome에 mapped 작업하지 말라고 합니다.
Re-sequencing하는 경우라면 변환해서 mapping하지 말고 원래 원본 파일 그대로를
input으로 하는 align 프로그램을 사용해서 mapped한 다음에 그 다음 작업을
일반적으로 사용하는 samtools나 GATK같은 프로그램을 사용하라고 합니다.
(다들 알고있는거 한번더 상기 시켜드렸습니다. 혹시 아나요 SOLiD 포맷을 분석하게 될지.. ㅎㅎ)

분석시 raw 파일을 사용해야 하는 이유는 SOLiD만의 월등한 quality 효과를 볼수 있어서
그러지 않겠나하는....  믿거나 말거나 저 혼자만의 생각입니다.. ㅎㅎ
다만, 타사 제품과 다르게 복잡하게 숫자로 표현한건 아니겠죠...
나름의 숨은 뜻이.... 쿨럭.. (설마... 간지용;;;;; )

Re-sequencing이 아닌 denovo일 경우 모 어쩔수 없이 fastq파일로 변환을 해야 하지 않을까 합니다. assembly 프로그램을 작동시키려면 아무래도 SOLiD format보다는 fastq 포맷이
수월하니깐요.. :)

그럼....