레이블이 Assembly인 게시물을 표시합니다. 모든 게시물 표시
레이블이 Assembly인 게시물을 표시합니다. 모든 게시물 표시

일요일, 11월 12, 2023

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


금요일, 10월 27, 2023

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

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

이름하여 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하나 올려둘 수 있도록 해봐야겠습니다. :)


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




수요일, 7월 20, 2022

Long Read 조립은 누가누가 잘하나

Piroplasm를 나노포어를 사용하여 genome project를 진행했고 나노포어를 활용한 assembler들에 대한 성능 비교 논문 되겠습니다.


제목은 Systematic Comparison of the Performances of De Novo Genome Assemblers for Oxford Nanopore Technology Reads From Piroplasm

doi는 https://doi.org/10.3389/fcimb.2021.696669


piroplasm이 몬지는 모르겠으나 일단 그렇게 엄청나게 복잡하지는 않은 원생동물이나 사람이나 동물들에게 질병을 일으키는 녀석 되는 것 같습니다. funding중에 동물 전염병 및 인수공통전염병 관련 프로그램이 있는것으로 보아하니...


여튼 중요한건 nanopore로 읽어낸 서열을 사용하여 genome 조립할때 어떤 어떤 조립 프로그램이 제일 좋은지를 검토해본 것이니 OLC (Over-Layout-Consensus)나 전통적인 de-Brujin graph, string graph-based 방법 등등의 NECAT, Canu, wtdbg2, Miniasm, Smartdenovo, FlyeNextDenovo, Shasta와 같이 일반적으로 long-read에 사용하는 assembler들을 비교 테스트 하였다고 합니다.

대신 여기서는 assembly의 정확도와 함께 CPU 사용량, 메모리 사용량, 분석시간 사용방법 등등에 대해서도 함께 평가했다고 합니다. 참 바람직한 태도라고 봅니다. 모든 연구팀들이 그래픽카드 4개꼽히고 6T 메모리의 4U 서버를 가지고있는것은 아니니 말입니다.


실험 방법은 prioplasm free한 양 2마리(??)에게 prioplasm을 감염시켜 잘 배양(??)시킨 다음 Qiagen 사용 prep kit을 가지고 DNA 추출하고 PromethION으로 시퀀싱하였고 데이터 셋트에 따른 assembly 결과 평가를 위해 6가지 생산량 (약 15x, 30x, 50x, 70x, 100x, 120x)의 셋트를 만들었다고 합니다. 그리고 추가적(aka error correction)으로 (일루미나와 특허 소송에서 승리한) MGI로도 시퀀싱을 하였다고 합니다.


여튼 결과적으로

N50과 contig개수(적을수록 좋음)는 생산량과 밀접하고,
분석 시간은 생산량이 많으면 어떤 assembler를 사용하던 길어졌고,
polishing은 안하는것보다 하는것이 좋은것 같고 각 tool의 장단점은 Figure3에 방사형 그래프로 이쁘게 표현하였으니 한번 참고하시면 좋을것 같습니다.

그래서 Miniasm, Flye, wtdbg2는 그닥 좋은 선택지는 아닌것 같고 평균 커버리지가 30x 이상 확보된다면 NECAT, Canu, NextDenovo, Smartdenovo가 더 나은것 같다 정도 되겠습니다.

(사실 위의 tool들을 실행시키려면 평균 30x 이상은 있어야 작동을 합니다. 안그러면 작동안하던지 말도안되는 결과들을 뱉어내곤 합니다.)


그리고 시간이 충분했는지 각 assembler 결과들을 병합/후처리하는 작업을 하여 더 나은 assembly 결과를 보여주는지 테스트 했고 몇몇 조합에서 결과물이 향상된것을 확인했다는데... dramatically 좋은 결과는 보여주지 않은것 같았습니다. 

만약 병합/후처리하는 결과가 좋았다면 논문 결과가 single assembler 쓰지말고 ensemble방법을 추천드립니다라고 했었을테니 말이죠.. 



출처: @candyz_hyojung


일요일, 5월 03, 2020

Long Read Assembler 설치 작업 로그

오랜만에 작업 로그용 글입니다. :)

Long Read(aka Nanopore)를 위한 assembler의 설치에 대한 로그로... 모 그렇게 자주 사용 될일이 없을것 같지만.. 그래도..

root권한 또는 sudo권한이 없는 상황을 가정하고 설치하는게...
나중에 편합니다. root권한 있으면 편하지만 나같은 쩌리한테 호기롭게 root권한이나 sudo를 부여할 이유가 있겠습니까? 그냥 없으면 없는대로 사는법도 알고 있어야... :)


canu (https://github.com/marbl/canu/releases)

$ wget https://github.com/marbl/canu/releases/download/v2.0/canu-2.0.Linux-amd64.tar.xz

$ tar -xvf canu-2.0.Linux-amd64.tar.xz

또는

$ git clone https://github.com/marbl/canu.git

$ cd canu/src

$ make -j <number of threads>


wtdbg2 (https://github.com/ruanjue/wtdbg2)

$ git clone https://github.com/ruanjue/wtdbg2

$ cd wtdbg2 && make


Raven (https://github.com/lbcb-sci/raven)

$ git clone --recursive https://github.com/lbcb-sci/raven.git raven

$ cd raven && mkdir build && cd build

$cmake -DCMAKE_BUILD_TYPE=Release .. && make

$ ./bin/raven

단, raven은 cmakr 3.9이상이 필요합니다. cmake 설치는 아래에 따로..


Racon (https://github.com/lbcb-sci/racon)

$ git clone --recursive https://github.com/lbcb-sci/racon.git racon

$ cd racon

$ mkdir build

$ cd build

$ cmake -DCMAKE_BUILD_TYPE=Release ..

$ make

racon의 경우 raven이 아닌 miniasm_and_minipolish.sh 작업시 racon을 찾아 해매서 racon 설치도 진행하였습니다.


flye (https://github.com/fenderglass/Flye)

$ git clone https://github.com/fenderglass/Flye

$ cd Flye

$ python setup.py install --prefix=/path/to/install/

또는

$ python setup.py install --user

※ --user 라는 옵션이 갱장히 편합니다. 대신 나만 됩니다.





cmake (https://cmake.org/)

$ wget https://cmake.org/files/v3.10/cmake-3.10.3.tar.gz

$ /bootstrap --prefix=/path/to/install/

$ make

$ make install

※ prefix를 설정하지 않으면 /usr/bin 모 이런데에 설치 되므로 설치가 제대로 되지 않기 떄문에 prefix를 설정하는것이 정신건강에 이롭습니다. :)



출처: @sana_twice.09


화요일, 2월 14, 2017

A5 pipeline


논문: An Integrated Pipeline for de Novo Assembly of Microbial Genomes

다년간 Non にんげん  denovo aseembly를 하다보니 별별 라이브러리 조합을 만나 봤는데
A5 파이프라인이 이 별별 라이브러리 조합에서 의외로 괜찮은 성능을 보여주는 관계로
다른 좋은 파이프라인이 있지만 라이브러리 조합이 내맘같지 않을때 한번 써보시라고 소개글 하나 투척

A5 (aka Andrew And Aaron's Awesome Assembly pipeline)
>DOWNLOAD<

대게 short read의 경우 SOAPdenovo, ALLPATH-LG 결과에 SSPACE로 스캣폴딩이
일반적인데 이게 내가 직접 라이브러리 디자인을 못할 때 뜬금없는 라이브러리 조합으로
시퀀싱 데이터를 영접할 때에 의외로 성능이 안나오셨을 때가 있으실겁니다.

고갱느님께서 나는 시퀀싱을 했으니 complete sequence를 내놔라.
어차피 complete sequence 안나오는거 앞뒤없이 complete 외친 분 제외하고는 다 압니다. ㅎㅎ
걱정마세요.

너님이 named가 아니라서 못하는것이니 노오오오오오오력을 해라
라는 말만 되풀이 하시니 어쩌겠습니까 일단 해야죠  ㅋㅋ :)

이때 사용할 만한 파이프라인 되겠습니다.

물론 complete 안되는게 이 파이프라인 돌리면 complete가 된다는 건 아닙니다.

그나마 SOAPdenovo/ALLPATH-LG에서 돌리는것보다는 상대적으로
통계치가 우수해집니다. 절대적으로 이 결과가 좋다는 아닙니다.
N50 개수 줄고 Max Length 조금 길어지고.. 모 그정도..
(그리고 언제나 A5 결과가 SOAPdenovo, ALLPATH-LG보다 좋다는것도 아님을 밝힘 ㅋ)

중간에 SGA써서 SGA셋팅이 최적화되어 있다면 문제 없는데 SGA를 위한 셋팅이 안되어 있다면 시간은 좀 오래 걸릴 수 있습니다.

본인의 경우 그냥 돌려놓고 당분간 까먹고 있으면 결과는 나오더라구요.

최근에 하나 돌릴게 있어서
문뜩 생각나서 소소하게 A5 파이프라인 글 올려봅니다.

월요일, 4월 04, 2016

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로 하면 싼것처럼 느끼게 하려는 고도의 노림수인가;;;

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

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

금요일, 7월 12, 2013

Velvet으로 Assembly하기

결론은 de novo는 흠좀무라는... ㅋㅋ

species가 무엇이 되던간에 말입니다. ㅎㅎ


요즘 몇몇 곰팡이를 조립중에 있는데
SOAPdenovo, Velvet, SPAdes, SSPACE를 중점적으로 사용하고 있습니다.
ALLPATHS-LG는 read 준비하는 것까지는 작동을 하는데
그다음에 본 작업에서 error를 뱉고 죽어버리는 어처구니 없는 상황을 연출해주는 바람에
일단 pass했습니다.

여러 strategy으로 접근 중에 있는데...

아... 본 글은 그게 중요한게 아니라... (다음 기회에 언급 하도록 하겠습니다.)

Velvet assembly할 때 long insert library (Mate-Paired Library)를 한개만 지원하는 것 같아그 문제를 해결하가 위한 tip입니다.

해결 방법은 다음 링크에 나와 있습니다.


EMBOSS의 "revseq"를 사용하면 안습이 된다는 것 빼고는 말이죠~ :)

그래서 준비 했습니다.


#!/usr/bin/python
import os,sys
from Bio.Seq import Seq
from Bio.Alphabet import IUPAC

def readread(s):
        return [s.readline(),s.readline(),s.readline(),s.readline()]


try:
        fq = sys.argv[1]

except:
        print "python command.py <input_fastq>"
        print ""
        exit(1)

fq_open = open(fq,"r")

fq_write = open("%s.rev" % (fq),"w")

s1read = readread(fq_open)

while(s1read[0]):
        h1, h2 = s1read[0].strip(), s1read[2].strip()
        s1, q1 = s1read[1].strip(), s1read[3].strip()

        rev = Seq(s1,IUPAC.unambiguous_dna).reverse_complement()
        qual = q1[::-1]

        fq_write.write("%s\n%s\n%s\n%s\n" % (h1,rev,h2,qual))

        s1read = readread(fq_open)

fq_write.close()

-위 소스는 python 2.6 이상에서 작동합니다. :)

velvet으로 조립 시 mate-paired Library가 여러개라면 서열을 변경 한 이후 사용해 보시기 바랍니다. :)

토요일, 9월 01, 2012

Velvet 사용 Tip

작년부터 NGS, NGS 해서 한두번쯤은
많은 NGS 프로그램들을 들어보셨을 것이고
조금이라도 관련되어 있는 일을 하시는 분이라면
이미 많이사용해 보셨을 것이라고 생각됩니다.

오늘은 그중에서 Velvet, sequence assembly 프로그램에 대해서..

Velvet은 de Bruijn graph 알고리듬을 사용했다고 합니다(라고 메뉴얼에 적혀 있습니다.
물어보지 마십시요. 저도 몰라요 ㅠ.ㅜ ).

여하튼 assembly 프로그램은 제가 알고 있는 바로는 크게 두가지
velvet과 같이 graph 알고리듬을 사용하는 프로그램과
아니면 sequence overlap 방법을 사용하는 프로그램이 있습니다.

그중에서 전 velvet이 좋은데 왜냐?
사용하기가 간편해서 입니다. ABySS나 ALLPATH-LG와 같이 복잡미묘하지 않기때문이죠
(간단하기로는 BGI의 SOAPdenovo가 최고봉인듯;;; )
단, velvet의 경우 big size의 genome을 assembly 할때는 고성능 CPU도 중요하지만
대용량 RAM도 함께 준비하시기 바랍니다.
물론 Big Size genome이라서 RAM이 많이 필요 한게 아니라 assembly read 개수가 많기 때문에
대용량 RAM이 필요한것이니.. ㅎㅎ assembly에 사용할 read 양이 적으면 상관없습니다.
다만 assembly에 사용할  read양이 많으면 대용량 RAM은 필수라는 것 잊지마시기 바랍니다.
-RAM이 작아도 작동은 하지만 swap을 사용하므로 결과 보시기 힘드실겁니다. ㅋ

곰팡이를 assembly 해본 경험으로 미루어 Velvet 에서의 RAM 요구량을
대략 적어봤습니다.
Total Input (Giga) 
Memory (Giga)
40
256
20
128
10
64
5
32
2
16
1
8

Velvet으로 assembly할때는 일단 RAM은 많으면 많을 수록 좋습니다. :) ㅎㅎ

그럼 오늘 포스팅은 여기까지 ㅋ