HTML

Az élet kódjai

Csináld maga. Senki nem csinálja meg helyetted.

Friss topikok

  • sdani: Sajnos nekem is hasonló érzéseim vannak az R kiszorulásával kapcsolatban. Remélem jobban fogja tar... (2024.04.29. 10:48) R meetup
  • sdani: Nagyon jók ezek a bejegyzések! Feszültséggel teli, fordulatos, mint egy jobb krimi. :D Abba ne hag... (2024.04.29. 10:35) Wgel CTF
  • sdani: @Travis.CG: Egy kis szerencse sosem árt. :D (2024.03.01. 13:19) A bioinformatika helyzete 2024-ben
  • Travis.CG: Szóval az akadémiai szféra mazochistává tett, amit a Pinephone-al élek ki? Hmm, érdekes összefüggé... (2023.10.05. 18:23) Új barátom az Informatikai titkárságról
  • Travis.CG: Túl nagy a hype körülötte, ezért túlzó elvárások vannak vele szembe. Ha a korábbi chatbotokhoz kép... (2023.02.28. 06:28) chatGPT, a bioinformatikus

Hi-C elemzés

2021.01.10. 21:32 Travis.CG

Habár előszeretettel hivatkoznak a DNS láncra, mint egy hosszú szalagra, ahol csak a nukleotidok sorrendje az egyedüli fontos ismertetőjegy, a valóságban a DNS egy komplex struktúra, ahol külön logisztikát igényel a sejttől, hogy ezt az információt valahogy tárolja.

A DNS ezért nem egy összekuszált fonalgombolyagra hasonlít, amivel három macska játszott, hanem egy kazettákban használt hang szalagra. Ezt kromatinnak hívják. Az előbbi analógia természetesen sántít, mert ha szükségünk van egy dalra, ami a szalag közepén van, folyton tekergetni kell a magnót, hogy mindig azt a részét halgathassuk, amelyiket akarjuk. Ezt az időveszteséget a sejt nem engedheti meg magának, neki úgy kell feltekernie a DNS-t, hogy közben elérhesse azokat a géneket, amelyekre szüksége van. Ezért a kromatin állapot folyton változik a sejt aktuális szükségleteinek megfelelően.

A kromatin még ennél is többet tud! A DNS különböző pontjain fellelhető információnak néha egy helyen és egy időben kell jelen lennie. Mintha a korábban említett kazettán a dalok hangszerei külön lennének felvéve, de lejátszásnál mégis egyszerre hallatszana minden. Ezért a génkifejeződés közben bonyolult térbeli struktúrák jönnek létre, amikor távoli DNS részek közel kerülnek egymáshoz. A Hi-C szekvenálás pontosan ezen struktúrák elemzésére szolgál.

A segítségével megállapítható, hogy egy adott gént milyen távoli enhanszerek szabályoznak. De előszeretettel használják kromoszóma összeépítésre is, mivel ezek a struktúrák általában egy kromoszómán belül jönnek létre és a távolságuk sokkal nagyobb is lehet, mint bármelyik harmadik generációs szekvenálás read hossza.

Először is kovalensen kötik a feltekeredett DNS darabok egymáshoz közeli részeit, ami olyan, mintha pillanatragasztóval fixálnák ezeket a kötéseket. Ezután egy restrikciós enzimmel levágják a hosszú DNS darabokat, amelyek ezekről a fixált részekről lelógnak. Az eredmény tehát egy nagy csomó lesz, amiről rövid DNS láncok lógnak le. Ezeket a szabad láncvégeket összekötik, majd a szekvenálják.

A bioinformatikai elemzés ebből a sajátos laboratóriumi előkészítésből adódóan nagyon eltér a többi második generációs szekvencia elemzésektől. Először is, a read párok távolsága nem követ normál eloszlást, emiatt nem is együtt illesztik őket, hanem mintha külön szekvenciák lennének. Másodsorban a genom adott pontján található read mélységnek nincs információ tartalma. Két genomi pozíció összekötésénél nem az számít, hogy hány read esik egy pontra, hanem hány ilyen pont van, ami megerősíti, hogy kapcsolat van két pozíció között.

Rengeteg program van, amivel feldolgozhatjuk adatainkat, én csak egyet mutatok be, ez pedig a Juicer. Azért ezt, mert erre a protokollra építkezve nem csak a szabályozó kapcsolatokat lehet elemezni, hanem egy genom-összeszerelő módszer is épül rá. Így egy eljárással két bioinformatikai módszert is ismertethetek.

A Juicer nem millió parancssori paraméterrel működik, hanem egy rögzített könyvtár struktúrával dolgozik. Ebbe a könyvátrba helyezzük a references alkönyvtárat a referencia genomokkal, a fastq-t értelem szerűen a fastq fájlokkal. Végezetül a scripts könyvtárba kell helyeznünk azokat a Juicer szkripteket, amelyekkel dolgozni akarunk. Ugyanis a fejlesztők minden platformhoz készítettek egy szkript halmazt, amit különböző alkönyvtárakba helyeztek el (nézzük csak meg a Github repójukat). Például ha csak egy gépen akarunk futtatni, akkor a CPU alkönyvtár szkriptjeit helyezzük el itt. (Vagy csak egy linket helyezünk el). Ez nem egy professzionális megoldás, főleg, ha azt nézzük, hogy már létezik Snakemake. Vitathatatlanul ez az egyik gyengesége a programnak.

Első lépésként a BWA-val indexelni kell a referencia szekvenciát. Ezt nem írom le, gondolom a könyökén jön ki mindenkinek, aki szekvencia feldolgozással foglalkozik.

Ha ezekkel megvagyunk, el kell készítenünk a restrikciós helyek térképét, amihez a Juicer misc alkönyvtárában találhatunk egy szkriptet.

python generate_site_positions.py enzimname reference.fa restrictionfile

Sajnos az enzim nevek a programba vannak égetve. Van HindIII, DpnII, MboI, Sau3AI, Arima. A referenciából kell még készítenünk egy kromoszóma méret táblázatot is, amit a samtools-al készíthetünk el, de csak az első két oszlopra van szükségünk.

samtools faidx reference.fa
cut -f 1,2 reference.fa.fai >reference.chrom.sizes

Ha mindezekkel megvagyunk, indíthatjuk a programot:

scripts/juicer.sh -D workdir -z reference.fa -y restrictionfile -p reference.chrom.sizes

Eredményül fogunk kapni egy .hic kiterjesztésű állományt. Minden további munka, ezzel a fájllal megy.

Rövid vizuális áttekintésre használhatjuk a Juicebox alkalmazást. Javaban írták, és hála a hic tömörített formátumának, akár egy erősebb laptopon is elfut, bár ne reméljünk eget rengető sebességet.

A Juicer egyik kimenetét használhatjuk genom összeszereléshez is, ha referenciának használjuk a scaffoldokat. Ehhez egy másik programra lesz szükségünk, a 3d-dna-ra. Telepíteni nem kell, csak ki kell bontani. A fent említett könyvtár struktúrában a Juicer hatására létrejön egy aligned könyvtár, amiben van egy merged_nodups.txt fájl. Gyakorlatilag erre és a scaffold fájlra van szükségünk. A program támogatja a diploid genom összeszerelést is.

./run-asm-pipeline.sh -m diploid reference.fa workdir/aligned/merged_nodups.txt

Az eredmény a reference.FINAL.fasta lesz.

Természetesen ritka, hogy egy kísérlet hibamentesen fusson. (Ha mégis így van, utóbb kiderül róla, hogy felesleges volt elvégezni.) Szükség van rá, hogy megtudjuk, melyik lépésnél keletkezett a hiba.

Ha az emésztés valamilyen okból nem volt sikeres, akkor azt látjuk, hogy a read párok elhelyezkedése közeli. Közeli alatt azt értem, hogy olyan, mintha egy közönséges DNS illesztés lenne, tehát a fragment távolságok normál eloszlást fognak mutatni.

Ha az emésztés sikerült, de a ligálásnál történt valami malőr, akkor az intrakromoszómális és interkromoszómális fragmentek aránya kisebb lesz. (Az érték egyébként humán vonatkozásban 80 szokott lenni.) Ezt az értéket a Juicer ki is számolja nekünk.

Ha megnézünk egy tipikus Hi-C ábrát, azt látjuk, hogy a főátlóban helyezkedik el a legtöbb fragment, a TAD-ok közelében. Amennyiben nem ilyen az ábra, kezdhetünk gyanakodni, hogy valami gubanc történt.

Felhasznált irodalom:

Bryan R. Lajoie, Job Dekker, Noam Kaplan: The Hitchhiker’s guide to Hi-C analysis: Practical guidelines

Szólj hozzá!

Címkék: bioinformatika

A bejegyzés trackback címe:

https://cybernetic.blog.hu/api/trackback/id/tr5216265276

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása