HTML

Az élet kódjai

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

Friss topikok

  • Anakin Solo (a.k.a. Ape): Jó öreg Winamp... mai napig azt használom, persza a 2.95 verziót :D Az még szinte tökéletes volt. (2016.11.09. 15:54) Túlprogramozás
  • Szedlák Ádám: Ha nem is egy hirdetést, de egy jó keresztrejtvényt! www.telegraph.co.uk/history/world-war-two/111... (2016.10.20. 11:34) Rejtett bioinformatikusok
  • Kalle: @Travis.CG: Jogos a felvetés, itt egy undorító c-szerű saját nyelven fejlesztenek, aminek köszönhe... (2016.08.05. 10:40) Ez itt a reklám helye
  • Travis.CG: Ez egy teljesen kitalált történet. Bármi kapcsolata a Virgin Mediaval vagy a BT-vel csak a paranoi... (2015.11.23. 00:11) Internet
  • Travis.CG: Az első cikkeim labormunkán alapulnak, sőt egyetem alatt még ökológus szakdolgozó is voltam. Későb... (2015.11.23. 00:06) Ez már nekem sok

Érdekes beszélgetés egy fizikussal

2017.02.20. 00:59 Travis.CG

Itt a Sangerben hihetetlen figurákkal lehet összefutni. Az egyikük Tony, aki az EBI-nál a szekvenciák tárolásával foglalkozott. Előtte 15 évig a CERN-ben volt, hogy a részecske ütköztető által generált töménytelen adat tárolását megoldja. Elég jó rálátása van mindkét tudományterületre, a jelen poszt a vele folytatott beszélgetés kivonata.

A két terület közel azonos mennyiségű adatot tárol. Korábban a részecske fizikusok vezettek, de már a szerves vonalon is kezdünk annyi információt felhalmozni, hogy nincs okunk szégyenkezni. De még mi mindent központosítunk (NCBI, EBI, DDJB), addig ők elosztott adatbázist használnak. Nem félnek attól, hogy adat-paraziták menő cikkeket írnak mások keservesen összekuporgatott eredményeiből.

Érdekes módon a detektor által gyűjtött anyag nagy részét eldobják. Ez egy biológus számára felfoghatatlan, mert míg mi nem tudjuk, mikor lesz később szükség valamire, addig a fizikusok pontosan tudják, hogy mi az, ami soha az életben nem fog kelleni. Nem is tárolják. Pontos arányokra nem emlékszem, de szinte csak töredék információt tárolnak. (Ami így is elég nagy, hogy álmatlan éjszakákat okozzon Tony-nak és csapatának.)

Ez a tervezett hozzáállás egyébként az adatfeldolgozás minden lépésére jellemző. Mint megtudtam, a LHC építése előtt már megvoltak a fájl formátumok, programok, minden, ami a kiértékeléshez kell. A részecskefizikusok 15 éves formátumokkal dolgoznak, változtatás nélkül. Nálunk ez egy kicsit kaotikusabb: Juj, kéne valami, amiben tároljuk az illesztést. Kész a SAM. Ja, ez helypazarló, csináljunk BAM-ot. Most jut eszembe, hát ott a referencia, minek tároljunk redundáns információt. Nesze, itt a CRAM. De még a jó öreg FASTA is mennyit változott az idők során. És akkor a különböző kutatók által kidolgozott dialektusokról ne is beszéljünk.

Ugyan ez áll a programozási nyelvekre is. A fizikusok sokáig Fortranban írták a kódot és Tony állítása szerint egy kollektív döntés volt, hogy áttérnek C++-ra. Én már annak is örülök, ha egy bioinformatikai program csak nyelven íródott (IRAPTrinity).

Az alkalmazott módszerek viszont gyorsabban változnak nálunk. Amit ma napi szinten űzünk, nem biztos, hogy öt év múlva is csinálni fogjuk.

Szólj hozzá!

Címkék: filozofálás bioinformatika

A Mindentcsináló

2017.02.06. 01:49 Travis.CG

Még tavaly nyáron elmentünk az egyik angliai élményparkba. Elég sok ilyen van, közös jellemzőjük, hogy kiakakítanak egy egyéni stílust, majd telezsúfolják ugráló várakkal és szurikátákkal. De komolyan, néha már az az érzésem, hogy ezek az állatok innen származnak.

Ez a látogatás nem sikerült zökkenőmentesen. Kicsit felületesen néztem meg az odavezető utat, aminek az lett a következménye, hogy a sokadik busz, amivel aznap mentünk, kitett minket egy város széli megállóban és én nem tudtam, merre menjünk tovább.

De nem voltunk egyedül. Egy másik, népesebb indiai család is oda igyekezett, amit a sofőrrel folytatott beszélgetésükből tudtam meg. Beszélgetni kezdtünk és együtt tettük tettük meg az a két kilómétert, ami még hátra volt. A végére már járda sem volt, csak az autóúton bandukoltunk, libasorban. Ők még babakocsit is vittek. Biztos remekül mutattunk, de az autósok remekül tolerálták kis karavánunkat.

Kiderült, hogy a családfő a Thompson Reutersnek dolgozik, valami rákkutatással kapcsolatos részlegben. Hiába, itt Cambridge környékén köpni sem lehet, hogy el ne találnánk egy molekuláris biológust. Minden áron beszélni akart velem a bioinformatikai elemzésekről.

Megbeszéltünk egy találkozót, amolyan munkaebédet, ahol megtudtam, ők készítik a Mindentcsinálót. A program nevére nem emlékszem, csak arra, hogy differenciál expressziót számol, anyagcsere utakat elemez, asszociációkat határoz meg és potenciális rákterapeutikai célpontokat is visszaad. Természetesen, ahogy frissen szerzett barátom elmondta, rajtam kívül mindenki ezt használja.

Az eszköz egy weboldalon keresztül üzemel, de van hozzá REST API, ami a hozzám hasonló vén csontoknak szánt csali, hogy ráharapjanak. A mögötte megbúvó adatbázist manuálisan kurálják és naponta jelenik meg hozzá frissítés. Tehát kétszer nem lehet úgy elvégezni egy elemzést, hogy ugyan azt az eredményt kapjunk.

A legjobb dolog persze hátravolt: mindezt a kísérletet végző kutató tudja futtatni, bioinformatikus segítsége nélkül.

- Mit gondolsz, mit tenne a főnököd, ha ilyen szoftvere lenne? - kérdezte tőlem a fickó.
- Kirúgna engem - mondtam rövid gondolkodás után. Erre a válaszra nem számított.

Azt tudni kell minden üzletkötőről, hogy csak pozitív üzenetet szeretnek sugározni, amit a hasonló ügyfelekkel történő beszélgetések során jól be is gyakorolnak. Ha ez a jól bevált séma léket kap, összezavarodnak. Most is ez történt. Elkezdte mondani, hogy akkor én mást csinálhatok. Megkérdeztem, ugyan mit? Ettől még jobban összezavarodott. Végül megsajnáltam és azt mondtam neki, csak vicceltem. Ekkor megnyugodott és visszatért a beszélgetés az általa irányított mederbe.

De a helyzet az, hogy tényleg nem tudom, mi lenne a feladatom egy Mindentcsináló mellett. Talán az adatok Mindentcsináló-kompatíbilis formára alakítása? Vagy csak olyan elemzéseket végzek, amire a program nincs felkészítve?

A fickó azzal próbált még győzködni, hogy a bioinformatikai elemzés szokott lenni a szűk keresztmetszet. Ezzel a kijelentéssel vitatkoztam. Én úgy tapasztaltam eddig, hogy nem az elemzés volt a publikációk gátja, hanem a szekvenálás sebessége. Itt a Sangerben kb. 4-6 hónapig terjed, mire a DNS mintákból szekvencia adatok lesznek. Nekem utána egy hét elég, hogy az elsődleges eredményeket tálaljam (ha szabvány elemzés kell. Egyéni kísérleti elrendezésnél persze minden sokkal tovább tart.).

Természetesen az ábrakészítés lassan megy, mert a minták sorrendje rossz, a színek nem illeszkednek a publikáció színvilágába, vagy egyeszerűen csak, miért használok logaritmikus skálát? Ezen egyetlen program sem fog segíteni.

Ami még lassan szokott menni, az az, amit én csak képernyő bámulásnak hívok. Tudjátok, amikor ott van előtted minden információ és fogalmad sincs, hogy ez mit is jelent. Nem nyomsz le egyetlen gombot sem. Az egér mozdulatlanul pihen a kezed alatt. Az agyad meg max fordulatszámon pörög (vagy rossz esetben sokkhatás alatt áll).

Ilyenkor megy a szöszmötölés: ennek a génnek furcsa neve van, mit csinál? Miért nem találom a kutató kedvenc génjét a listában? Az adatok két harmada miért viselkedik ellentétesen, mint ahogy várom? A képernyő bámulást még a Mindentcsináló sem tudja felgyorsítani.

Búcsúzóul megkért, hogy a főnökömnen feltétlenül meséljek a Mindentcsinálóról én meg azt hazudtam, hogy természetesen. Eljátszottam a gondolattal, hogy írok neki egy levelet: A főnök úgy döntött, megtart engem és nem használja az Önök programját. Indoklás: a fizetésem kevesebb, mint a szoftver havi díja.

Szólj hozzá!

Címkék: életmód

Klaszter adminisztráció

2017.01.29. 01:37 Travis.CG

A klaszter adminisztráció nem egyszerű feladat. Emlékszem, még az egyetem alatt az egyik tanár mesélte az új labor felállításáról, hogy a telepítést úgy oldották meg,  hogy egy gépre elvégezték, majd a dd paranccsal a többi gép merevlemezére másolták azt. Nyilván, ha egyforma gépeink vannak, azokat ugyan olyan feladatot látnak el, ez működik is.

A mai klaszterek nem homogének. Változatos konfigurációban állnak rendelkezésre és van közöttük webszerver, tárolásra kialakított gép és számításokat végző egységek. A helyzetet bonyolítja, hogy ezek a szerepek az idő folyamán változhatnak.

Miként biztosítsuk a flexibilitást és a könnyű kezelhetőséget? A Sangernél az OpenStack használatával. Minden egységen egy virtuális gép fut, és ezen gépekre távolról rakják fel a képfájlokat. Ha valamelyik gépnek új funkció kell, csak a megfelelő képfájlt kell ráküldeni és már kész is. Gyakorlatilag ezt a módszert alkalmazzák az Amazonnál is. Csakhogy nekik nem kell törődni a szoftver környezettel, mert az a felhasználó dolga.

Itt viszont ha frissíteni kell egy programot, akkor új képfájlt kell létrehozni, ami lehetőleg hibamentes (tehát tesztelni kell), lehetőleg automatikusan készüljün el (ne kelljen a nulláról installálni mindent, csak mert megjelent egy új verzió az awk-ból) és az sem árt, ha a képfájl elkészítésének folyamatát egy verzió követő rendszerben megőrizzük.

Természetesen mindegyikre van megoldás. Jöhet a szakzsargon zsonglőrködés.

A verziókövető rendszer a Git, gondolom nem kell bemutatni. A stabil verzió a fő ágon van, minden újítást egy másik ágon kezdenek. Ha elkészültek a módosítással, letesztelték azt, mennek vissza a fő ágra. Akár csak egy szoftver fejlesztési projektnél. De a Git alapvetően kódot (szöveges állományt) tárol. Milyen kód kerüljön bele?

A virtuális képfájlokat a Packerrel készítik. Ez egy konfigurációs állományt állítja elő kódból. Támogat számtalan virtuális környezetet, tehát ha valami miatt az OpenStack nem válik be és egy másik technológiát kell követni, a Packer kód változatlan maradhat.

Az elkészült képfájl fordítását ellenőrizni kell, mert több száz program telepítése során igen sok hiba fordulhat elő. Erre a GitLab CI-t (continuous integration)  használják. Ha a CI nem talál hibát, a képfájl elkészülhet.

Ezután a kész képfájlt kell ellenőrizni, hogy a számtalan szoftverkomponens nem ütközik-e. Itt bizony nincs mese, a képfájlt telepíteni kell egy tesztgépre és különböző tesztprogramokat kell futtatni. A Test Kitchen célja pontosan ez. Csupán egyetlen konfigurációs fájlt kell készíteni és a rendszer lefuttatja a benne definiált teszteket.

Magukat a teszteseteket nem a Kitchen definiálja, az csupán egy keretrendszer. A tényleges tesztek Bats-ban futnak. A szoftver komponenseken kívül a szerver állapotát is tesztelni kell (felcsatolta-e a meghajtókat, müködik-e a hálózati csatoló, stb.), amire ServerSpec-t használnak.

Tehát ha új szoftver kell a klaszterre, először frissítik a Packer képet, a régi, stabil verzió felépítése megtalálható a Git-en. Megírják a teszteket, lefuttatják azokat, majd küldik ki a képfájlokat a csomópontokra. Igen, kicsit összetettebb, mint a dd.

Szólj hozzá!

Címkék: rendszergazda cloud computing

A dolgok mélysége

2017.01.23. 01:36 Travis.CG

Kijött az idei első cikk! Az elemzés egyik lépéséről már készült egy korábbi poszt. A vizsgált régióra még a tesztelésre megkapott egyik MinION-t is ráengedtük, de nem volt elég nagy a lefedettség, hogy bármi érdemi eredményt kapjunk.

Amilyen gyors volt a bioinformatikai elemzés, a kísérletes validálás annál lassabban ment, de ez nem is meglepő, mert elég sok fajtán kellett letesztelni az eredményeket és nincs mindenhol pipettázó robot. A mélység tehát nem csak a szekvenálásban, de a kísérletes oldalon is megvolt.

Sok pletykálni való nincs, a vizsgálat szempontjából érdekes variációk nagyon hamar a feltűntek, de akkor még nem tudtuk, mit is jelent ez. Mivel a kódoló régióban vártuk az érdekes mutációkat, meglepett minket, hogy a promóterben volt. Minden esetre a későbbi vizsgálatok alátámasztották a mutáció jelentőségét.

Ezt a projektet is nagyon szerettem, mert előtte még soha nem dolgoztam poolozott mintákkal. A témát alaposan körbejártuk (vagy inkább járták, mert abban már nem vettem részt) és a cikk is szép kerek egészet alkot.

Szólj hozzá!

Címkék: publikáció

Elixir

2017.01.19. 02:42 Travis.CG

Hétfő óta nincs víz a lakásban. Ha megnyitom a csapot, csak valami furcsa hang jön ki rajta: MagyarországcsatlakozottazElixirhezMagyarországcsatlakozottazElixirhez...

Előző évben egy buszos beszélgetés alkalmával kiderült, hogy az Elixir egyik adminisztrátorával szoktam utazni. Mikor megtudta, hogy honnan származom, mindig csepegtetett egy kis információt az események aktuális állásáról. Mivel a csatlakozás folyamatában személyesen nem vett részt, túl sok érdemi dolgot nem tudott említeni, de mondta, hogy épp melyik stádiumban van a kérelem. De pont ebben a hónapban nem sikerült beszélnünk, ezért én is más csatornán keresztül értesültem a sikeres csatlakozásról.

Korábban egy félnapos Elixir bemutatót is szerveztek itt, a Campuson, amire nem mentem el, de akik ott voltak, csak annyit tudtak mondani róla, a kaja jó volt. A legtöbb leírás elég semmitmondó, tele olyan marketing szagú szövegekkel, mint biztonság, innováció, cloud, fenntartható fejlődés, stb.

Oké, mihez is csatlakoztunk? Az Elixir egy elosztott infrastruktúra lesz. Míg korábban mindent integrálni akartak egy kézbe, mint az EBI, most a feladatokat szétosztják az Elixir tagjai között. Magyarország szerepe a fehérje szekvenciával és felépítéssel kapcsolatos eszközök, adatbázisok fejlesztése lesz.

Ezen kívül az Elixir szárnyai alatt szerveznek képzéseket, biztosítanak számítógépes kapacitást, és segítik a kollaboráció kiépítését.

De azért nem véletlen, hogy kevés konkrétumot hallani. Ha megnézzük, a terveken kívül nem sok kézzel fogható dolgot látni. Most még hurrá fázisban vagyunk, mint a gyerekek a játszótéren, akik összegyűjtik a haverokat a nagy homokvár építéséhez. Remélem kitart a lelkesedés akkor is, ha piszkos lesz a kezünk.

Szólj hozzá!

Majdnem mindent az RNA-seq-ről (4.rész)

2017.01.16. 00:58 Travis.CG

Az illesztést követően meg kell határozni, hogy a vizsgált régiókra mennyi read esik. A vizsgált régió lehet gén, transzkript, de akár exon is. Annak ellenére, hogy ez első látásra egy egyszerű feladat, hamar érdekes kérdésekre kell választ adnunk. A régiók ugyanis átfedhetnek. Antiszensz transzkriptek esetén az átfedő régióból keletkező readek megfeleltetése nem egyszerű feladat. Az itt bemutatott programok végtelenül egyszerűen oldják meg ez a problémát: eldobják a readeket. Ezért is mondtam, hiába van szuper illesztőprogramunk, ha utána nem vesszük figyelembe a bonyolult esetekből származó eredményeket.

De ha egy génről több transzkript képződik, a közösen használt exonok miatt akkor is nehéz megmondani, melyik read honnan is származik. (És akkor még nem is beszéltünk alternatív UTR-ekről, intron megtartásról és az alternatív splicing többi fajtájáról.)

HTSeq

Ez a szkript egyszerű, mint a faék. Minden primitívsége ellenére sokáig egyeduralkodó volt. Nem csinál semmit, csak összeszámolja, hogy génünk, transzkriptünk mennyi readet tartalmaz és eldob minden olyan esetet, ahol a read származási helye nem egyértelmű. Annyira egyszerű, hogy sokáig még pozíció alapján sorba rendezett SAM fájlokkal sem boldogult (de ha tehetjük, ne használjuk ezt a funkciót most se). A dokumentáció szerint olvas BAM fájlokat, de a gyakorlatban én még ezzel nem találkoztam.

samtools view input.bam  | htseq-count -q -m intersection-nonempty --stranded=yes --idattr=gene_id -r pos  - reference.gtf >count_table.tsv

A fenti kód az esetek 80%-ban működik. Ha a "Maximum alignment buffer size exceeded while pairing SAM alignments" hibaüzenet jelenik meg, kénytelenek leszünk a BAM fájlokat név szerint rendezni. A másik rejtélyes esetem a programmal, amikor az egyik bioinformatikusunk optimalizáció végett kromoszómánként akarta elkészíteni a végső táblázatot. Az eredmény eltért attól, amit akkor kaptunk, ha egyben futtattuk a teljes genomon. Egy ideig nyomoztuk az esetet, de végül félbe maradt az ügy. Ha mindezek nem tántorítottak el senkit a használatától, megemlítem, hogy még lassú is.

FeatureCount

Ez a program méltó utódja az előbbinek. Gyors, hála az optimalizált kódnak, a változatos paramétereknek köszönhetően kellően flexibilis és képes az összes BAM fájlt beolvasva a teljes mátrix legyártására (bár ez sokkal több időbe kerül, mintha BAM-onként futtatnánk és utólag fűzzük egybe az eredményt.) Egyetlen dolog nem tetszik csak: rengeteg járulékos, felesleges információ van a kimenetben. A következő opciókkal a HTSeq-hez elég hasonló eredményt kapunk.

featureCounts -a ../annotation.gtf -t gene -f -s 1 -o count.tsv input.bam

A sorozatot kicsit felfüggesztem, és egy látszólag teljesen független témával fogom folytatni, de akár csak a sok szereplős, a szálak között ide-oda ugráló romantikus filmeknél, az összefüggésekre végül fény derül.

Szólj hozzá!

Címkék: bioinformatika

Fájltalan, szervertelen...agyatlan?

2017.01.11. 01:07 Travis.CG

A cím kicsit félrevezető. A fájl nélküli (filess) nem azt jelenti, hogy nincsenek fájlok. A szerver nélküli (serverless) esetén se gondoljunk arra, hogy a szolgáltatások a semmin futnak. A két koncepció csupán annyit jelent, hogy a fájlok és szerverek, mint elsődleges célok megszűnnek és helyüket átadják egy magasabb absztakciós szintnek. Mik is ezek a magasabb szintek?

Fájltalan

Erről a koncepcióról először a Broad Institute egyik előadásán hallottam, ahol az intézet infrastruktúrális hátteréről beszéltek. Náluk nincs hatalmas számítógép park, amit lehet, kereskedelmi felhő szolgáltatóknál oldanak meg. Ott tárolják a szekvenciákat, a metainformációkat, mindent. Amolyan jenki mentalitással, csapatmunkában dolgoznak. Tehát ha a Google-nek/Amazonnak van számítási kapacitása, akkor vesződjenek ők a biztonsági mentésekkel, rendszer frissítéssel és egyéb adminisztrációs gondokkal, a Broad meg vesződik a szekvenciák feldolgozásával.

Amiben más a koncepciójuk, az a szekvenciák tárolása. Egy BAM fájl ugyanis már nem elég az összes információ tárolására. Rákos mintáknál például vannak páciens adatok, a betegség előzményei de akár a könyvtár előkészítés, minta begyűjtés is fontos lehet. Ezeket a metainformációkat is tárolni kell. Egy hagyományos fájl alapú megközelítésben készítenek még egy fájlt (legrosszabb esetben egy Excel fájlt) ezek tárolására. De még ha adatbázist használnak is a tárolásra, akkor is a hagyományos fájl műveletek (másolás, átnevezés) könnyen inkonzisztens állapotba hozhatják azt.

Elsőre talán furcsa lehet ezt hallani, de ha belegondolunk, a mindennapi élet is hasonló kihívásokat tartogat. Vegyük csak a legegyszerűbb esetet, a fényképek tárolását. Normális esetben a fényképeket dátum és tematika szerint rendezzük egy könyvtár struktúrába. De bizonyára mindenki találkozott olyan esettel, hogy egy fénykép két csoportba is belefér. Mit csináljunk? Másoljuk két helyre? Hozzunk létre linket? Bármit választunk is, a hagyományos fájl alapú megközelítést használunk, annak minden korlátaival.

Szervertelen

Az Amazontól is tartott előadást egy ember. Ő az Amazon Lambda szolgáltatásról beszélt, ami - kicsit eltúlzott formában - a jó öreg callback függvények felhős megfelelője. Röviden arról van szó, hogy ahelyett, hogy szervereket konfigurálnánk, kódot írunk, majd beállítjuk, hogy a kód milyen esemény hatására fusson le (trigger).

Az előadáson a példa a fájl feltöltés volt. Adva van egy weboldal (természetesen ez is az Amazonon futott), ahol a felhasználó feltöltött egy képet. A kód elhelyezte azt az Amazon tárhelyére. Ezután a példát kiterjesztették egy mobilos alkalmazásra, ahol a kód változtatása nélkül, csupán egy új trigger hozzáadásával, immár mobilos felhő szolgáltatássá változtatták a programot.

Természetesen az egész csak az Amazon berkein belül, azok szolgáltatásaival összhangban működik, saját szerverrel mindez elképzelhetetlen. De hát ezért szervertelen, nem?

Szólj hozzá!

Címkék: cloud computing

Év végi összefoglaló

2017.01.01. 01:11 Travis.CG

Az idén sem lehet ok a panaszra. Megjelent öt cikk, ami nem is rossz. Feldolgoztam 980 egysejtes RNA-seq-t (egy PhD hallgatónak kellett segíteni a dissszertációjához), 40 organoid RNA-seq-t, 1085 sejtvonalból származó RNA-seq-t (az RNA-seq pipeline teszteléséhez kellett), 196 egysejtes fitymabőr adatot (de csak 37 volt használható), 1224 exome szekvenálást (bár ez még folyamatban van), 4 humán teljes genomot, 9 egér teljes genomot és 6 microarray-t. Oh, az 550 GTEx adatról majdnem megfeledkeztem, bár az is folyamatban van.

Azokat az eseteket nem számoltam, ahol nem a teljes feldolgozást, csak egy részfeladatot csináltam, vagy segítettem másoknak kitalálni, miért akadtak el a programok az adatokon.

Összehasonításképp, a Sanger előtt egész életemben 67 szekvenálási adatot dolgoztam fel (gyarló memóriámnak tudjatok be +- 20-t). Szintén nem számolva azokat az eseteket, ahol csak részfeladatot hajtottam végre, vagy kapilláris szekvenálással kapcsolatos munka volt.

Demoscene fronton mind a megjelent posztok számában, mind az aktivitásban visszaesés volt tapasztalható. Csupán egyetlen produkció született, azt is eléggé lehúzta a közösség. Nem, mintha olyan sok pozitív kritika született volna más alkalommal, de legalább újabb partival bővült a gyűjtemény.

Nem csak a szekvenálási adatok száma növekedett, de a számítógépes technológiák száma is. Számomra kezd nehezen követhetővé válni, melyik mire is jó. Már két olyan előadáson is voltam, ahol csak kulcsszavakat jegyeztem le, mert az előadó úgy dobálózott velük, mintha ezek nyilvánvalóak lennének mindenki számára. Ez elég ijesztő volt számomra.

A másik döbbenetes dolog számomra az okos készülékek fejlődése. Én nem vagyok egy nagy mobil guru (a 8 éves Nokiám a példa rá), de az egyik Linux magazinban a személyi asszisztenseket hasonlították össze. Annak idején, mikor megjelent a Siri, az egyik Alma fan lehozta Amiga klubba. Az egész akkor egy viccre hasonlított. Alig értette, mit akartunk, lassú volt, béna. Most viszont az volt a kifogásuk a tesztelőknek, hogy egyes asszisztensek fárasztó vicceket mesélnek. Mi van? Komolyan ez egy probléma?

A trendektől kezdek eltávolodni, de azért remélem a tatter bloggal maradtok jövőre is.

Szólj hozzá!

Címkék: filozofálás

Kit vegyünk be a cikkbe?

2016.12.30. 02:18 Travis.CG

Vége a hosszú, fáradságos munkának. Kész a kézirat is. A munkatársak, akik eddig együtt, vállvetve kutatták az ismeretlent, hirtelen ellenségekké vállnak és megkezdődik a harc, hogy milyen sorrendben legyenek a szerzők nevei feltűntetve.

De előtte még felmerül a kérdés: egyáltalán kit vegyünk be?

Az első kézenfekvő válasz: aki dolgozott az adott munkában. De mindenki tudja, hogy ez nem igaz. Az asszisztenseket nem vesszük bele, pedig ők is részt vettek a kísérletekben. A szerzősor végén pedig fel-feltűnnek olyan emberek, akik effektíve nem dolgoztak, de mégis nélkülözhetetlenek. Például mert adták a pénzt a világmegváltó vizsgálatokhoz vagy meghümmögték az eredményeket.

Akkor használjuk a következő definícót: akik nélkül nem jöhetett volna létre a cikk. Ez sem jó. A kutatók szülei sem szerepelnek a szerzőlistában (bár némelyik Nature cikknek annyi szerzője van, hogy a nagy számok törvénye alapján ez bekövetkezhet), sem a Microsoft Word fejlesztői. Valami pontosabb kéne.

Definiáljunk egy mérőszámot. Egy hányadost, ahol a számláló a hozzájárulásunk százaléka a munkához, a nevező pedig azoknak a cikkeknek a száma, amihez a fenti munka felhasználható. Ha ez a hányados átlép egy küszöbértéket, az illetőt bevesszük a cikkbe.

Tekintsünk el olyan apróságoktól, mint a "hozzájárulás százalékának" mérhetetlensége. Ez sem lenne teljesen objektív és a küszöbérték meghatározása sem olyan egyszerű. De tegyük félre ezeket és nézzük meg a mérőszám működését két szélsőséges esetben.

Tehát a Word fejlesztői mondjuk a munka 0.01%-t végezték, de ez a munka elméletileg az összes cikkhez hozzájárulás, hiszen majdnem mindegyik kéziratot Wordben írják. Tehát egy kicsi számot elosztunk egy nagy számmal: az eredmény a nullához közelít.

A PhD hallgató viszont a munka mondjuk 80%-t végzi, közben mással nem foglalkozik (hahaha). Ő átlépi a küszöböt.

Első körben a fenti mérőszám jónak tűnik, kellően objektív is. De ennek nincs jelentősége, mert a valóság az, hogy a levezető szerző teljesen önkényesen dönti el, kik legyenek bent.

Például nézzük ezt a cikket. Ebbe akár bele is vehettek volna. A munka alapjául szolgáló pályázatból fizettek, én csináltam a miRNS elemzést (ami valószínűleg újra megcsináltak) és később is rendszeresen küldtem a N. benthamiana homológ szekvenciákat nekik, mert a Blast keresés túl bonyolult volt. De eljöttem, elfelejtettek. Van egy olyan érzésem, nem ez lesz az egyetlen ilyen cikk.

Aztán itt van ez a cikk. Jóformán nem csináltam semmit, a munkát azután végezték, hogy eljöttem, csak egyfajta telefonos segítség voltam. Egyáltalán nem sértődtem volna meg, ha nem vesznek be. Mégis bevettek, mert úgy érezték a mérőszámom átlépi azt a bizonyos küszöbértéket.

Szólj hozzá!

Címkék: filozofálás publikáció

Algoritmikus Karácsonyi Ünnepeket

2016.12.24. 20:30 Travis.CG

Az egyik csoportvezetőnek YouTube nézés közben támadt az az ötlete, hogy karácsonyi dalokat algoritmizáljunk. Amolyan börtönös karatefilm szabályokat állított fel ("Az egyetlen szabály, hogy nincs szabály.") ésvárta a pályaműveket.

A folyamatábra nekem túl snassz volt, arra gondoltam, egy szándékosan túlbonyolított, nehezen olvasható kód működését kellene bemutatni, mintha egy hibakeresőben futna.

Elöször egy karácsonyi énekre volt szükségem, ami nagyon-nagyon redundáns. Meg is találtam. A második lépés egy Python kód megírása volt. Először megírtam szépen, hogy legyen egy referencia, majd fokozatosan elkezdtem a kódot tömöríteni és ezzel együtt nehezen értelmezhetővé tenni. De még így is inkrementálisan állította elő a szöveget. A végső verzióban viszont ezt is sikerült megváltoztatni, ami kicsit elrontotta a hibakereső-szerű bemutatót. (A refrénben ugyanis először elkészítem az ismétlődő részeket és utána szúrom be a nem ismétlődőket.)

A harmadik lépés demó-szerű lett, mert írtam még egy programot (C++), ami a zenére szikronizálva OpenGL-ben mutatja be a Python kód működését. Vizuálisan nem lett egy nagy eresztés, de nagyon jól szórakoztam az elkészítésével. Olyasmi volt, mintha Legóznék.

Végül videót is készítettem, mert a legtöbben almás PC-t használnak az intézetben, biztosan nem fogják lefordítani a kódot. Kipróbáltam az NVidia ShadowPlay felvevőjét, amit eredetileg a játékmenet rögzítésére találtak ki. Az elindítása nem volt teljesen triviális, mert nem tudtam, mire kell kattintani, ha aktiválni akarom a felvételi funkciót.

Legnagyobb meglepetésemre csak feketeséget vett fel, és csak akkor rögzítette a demót, amikor beállítottam a Desktop recording-ot. A végeredmény nem lett túl rossz, a tömörítési aránnyal is elégedett voltam. A textúrák kicsit kockásak lettek, talán további finomhangolással a minőséget is lehet javítani.

A nagy megmérettetés viszont elmaradt. A csoportvezető nem válaszolt az e-mailre és nem volt semmilyen visszajelzés. Egy hét elteltével is csak annyit válaszolt, hogy türelem. (Ellenálltam a késztetésnek, hogy azt írjam: türelmes vagyok, mint egy helpdesk kérés.) Többeket kérdeztem, egyáltalán tudnak-e valakiről, aki adott be valamit, de nemmel válaszoltak.

Remélem, azért Nektek tetszik:

Ha pedig valakit a kód érdekel, itt megtalálja.

Szólj hozzá!

Címkék: programozás demoscene

Jegyzeteljünk

2016.12.19. 01:10 Travis.CG

Mikor elkezdtem a PhD-t, témavezetőm adott egy hatalmas füzetet és elmagyarázta, hogyan kell jegyzőkönyvet vezetni: minden nap új oldalt kezdeni, dátum a jobb felső sarokban, oldalszámozás a jobb alsóban és az előző munkafázis oldalszámát feltűntetni. Spirálfüzetet elfelejteni, mert abból csak kitépődnek a lapok.

A módszerrel a legnagyobb problémám a kereshetőség hiánya volt, a másik a limitált hely, amit kitölthetek. Legtöbb esetben elég volt egy oldal, de néha nagyon sokat kellett írni és ha volt még két-három gélkép (amit a megfelelő ragasztóval kellett beragasztani), akkor átlógtam a következő oldalra és borult a rendszer, vagy csak helyet pazaroltam.

Ezért kezdtem el számítógépes jegyzőkönyvet vezetni. Közönséges HTML oldalak voltak, a fenti logikát követték, oldalszámozás helyett linkekkel lehetett manőverezni. A formázási lehetőségek limitáltak voltak, eszközök alig akadtak (emlékszik még valaki a Dreamweaverre? Úgy értem, mikor még a Macromedia tulajdonában volt.).

Aztán ahogy átnyergeltem bioinformatikára, minden munkafolyamatot számítógéppel kezdtem végezni, és jött a LaTeX. A formázási problémák megoldódtak, a dokumentumok szép ábrákkal bővültek, de a kódok beillesztése rendszeres probléma volt. Ha csak simán beraktam, a LaTeX fordító értelmezni akarta. Ha nyers szövegként illesztettem be, túlnyúltak a sorok a lapszélen. Nehéz volt megosztani a munkarátsakkal, az e-mailes küldözgetés nem volt jó megoldás.

Később jött a Wikipedia/Confluence. Sokáig ez volt a legjobb módja a jegyzőkönyv készítésnek és bizonyos esetekben mind a mai napig. Könnyű formázni, könnyű megosztani. De nem védett a humán gyarlóságok ellen. Ugyanis nem vagyok egy jó jegyzőkönyv író. Ezt többször a fejemhez is vágták, mikor elhagytam az előző munkahelyemet. Miért nincs jegyzőkönyv arról, hogyan töltöttem fel a szekvenciákat az NCBI-ra? Miért nincsenek a szkriptek még jobban kommentelve? Hogyan csináltam ezt vagy azt? A probléma az, hogy ami számomra triviális, azt nem írtam le. Ha nagyon belemerültem a munkába és gyorsan követték egymást a lépések, a jegyzőkönyv és a valóság inkonzisztens állapotba került, ami csak később derült ki.

Milyen jó lenne egy olyan rendszer, ahol a munkavégzés egyben dokumentáció is lenne! A Bash saját history-ja végül is ilyen, de nem derül ki, mit miért csináltunk, ráadásul a fájlok kimenetét sem tartalmazza. A Screen-nek is van saját előzmény listája, ráadásul a kimenetet is képes tárolni a Ctrl + A és h billentyű kombinációval, ami igen viccesen néz ki egy less vagy vim kiadása után. Az R is tárol minden lépést, amit végrehajtottunk, tehát a hibás paraméterekkel végzett lépéseket, elgépeléseket, mindent. Ez sem tökéletes.

Jó volna egy olyan rendszer, ami egyesítené a Wikipédia formázási lehetőségeit az R/Bash előzménylistájával, de csak azokat a lépéseket tartalmazná, ami tényleg szükséges a munkához, nem a szerencsétlenkedéseket. Igen, van ilyen rendszer. Úgy hívják IPython.

A rendszert úgy kell elképzelni, mint egy Wikipédiát, amibe ha beleírjuk a parancsokat, azok a rendszer végrehajtja. A kimenetek is a dokumentumba kerülnek. A forráskódot is formázza, ami csak hab a tortán. Ez LaTeX alatt szinte lehetetlen lenne. De azért ez sem jelent mindenre megoldást. Először is csak Python alatt működik, én meg egy csomó programozási nyelvet használok. Illetve a napi munka során hármat: Bash-t, amiben a farmra küldöm ki a szekvencia feldolgozást. Azok kimenetéből Python szkriptekkel táblázatokat készítek, végül R-ben csinálom a végső elemzéseket.

A másik, sokkal nagyobb gond, hogy az IPython azon a gépen kell, hogy fusson, ahol végzem az elemzést. Ez legtöbbször egy távoli gép, amihez csak ssh kapcsolatom van. (Igen, lehet X-et alagutaztatni, de aki használt már IGV-t ilyen módon, az tudja, hogy ez minden, csak nem hatékony munkavégzés.)

Ugyan ez a probléma az RStudioval, knitr-el, csak épp R oldalon. De erre is van megoldás!

A Jupyter olyan, mint az IPython, de sokkal több nyelvet ismert. Igaz, egyszerre csak egyet lehet használni. Két részből áll. A kernel, ami a számítási feladatokat végzi. Ez lehet egy távoli gépen is, csak a megfelelő portok legyenek nyitva. A kliens pedig egy böngésző képes számítógépen fusson. Mindent a böngészőből irányíthatunk. A dokumentumunk különböző cellákra van osztva, alapvetően két típusuk van: leírás és kód. A leírásba szépen megfogalmazhatjuk, melyik lépést miért csináljuk, a kód pedig azonnal végrehajtja azt. Azonnal. Itt el is érkeztünk a rendszer egyik hátrányához.

Az egész az úgynevezett interaktív programozás keretében nyer értelmet. Tehát ha van egy lépés, ami három napig fut, akkor nem érdemes Jupyteren keresztül használni. A másik fontos dolog, hogy ez nem szoftver fejlesző környezet. A tesztelést és hibakeresést nem támogatja.

Maga a fájl egy JSON, ezért akár GitHub-on keresztül tárolhatjuk a verziókat. Ha elgépeltünk valamit, csak kijavítjuk azt és újra futtatjuk az adott cellát, nem az egész munkafolyamatot. Vizsgálatunkat exportálhatjuk HTML-be, PDF-be, de akár fel is tölthetjük egy szerverre, hogy megosszuk másokkal.

De a legjobb dologról még nem beszéltem. Ez egy olyan tulajdonság, amivel egyetlen hagyományos jegyzőkönyv sem rendelkezik. Mivel alapvetően böngészőben fut, lehetőség van interaktív elemeket beszúrni. A legjobb példa erre a plotty, Az ezzel elkészített grafikonok tetszőlegesen nagyíthatóak, mozgathatóak. A jegyzőkönyv olvasója kódolási ismeretek nélkül is tanulmányozhatja az eredményeket. Megszűnik a papír jelentette korlát és kód a dokumentációval tökéletes egységet alkot, megőrizve mindent örökké. Vagy legalábbis amíg van áram.

Szólj hozzá!

Címkék: bioinformatika

Virtu...virtu...virtualizáció!

2016.12.16. 00:55 Travis.CG

Már nagyon ritka, hogy egy munkafolyamathoz csak egyetlen programot használunk. Sok programot, sok különböző beállítást használunk, gyakran egymással összeegyeztethetetlen konfigurációkban.

Az is problémát jelenthet, ha nincs rendszergazdai hozzáférésünk az adott rendszerhez, de programokat kell rá telepítenünk. A megoldás a virtualizáció lehet. Ebben a posztban virtualizáció alatt értem mindazokat a technológiákat, amelyek lehetővé teszik, hogy több környezetet működtessünk, de nem feltétlenül párhuzamosan.

Természetesen csinálhatunk mindent kézzel. Linux alatt a PATH, LD_LIBRARY_PATH környezeti változókkal beállíthatjuk, hogy programjaink honnan olvassák be a fájlokat. Ha Python-t használunk, a modulok helyét a PYTHONPATH változó határozza meg. R esetében is van lehetőségünk újra definiálni a csomagok helyét: R_LIBS, R_LIBS_USER, R_LIBS_SITE. Ez a megoldás nem nyújt 100% védelmet a konfigurációk ütközése ellen, de limitált hozzáférésű rendszereknél egy lehetséges megoldás. Nekem például volt olyan problémám, hogy egy számítógép klaszteren a fő gépen más konfiguráció volt, mint a munkát végző csomópontokon. Ezekkel a trükkökkel viszont felül tudtam bírálni minden beállítást.

Természetesen az egész hardvert is emulálhatjuk. Ha nincs például PPC processzoros gépünk, a hardver emulációjával elérhetjük, hogy legyen. Újgenerációs Amiga-szerü rendszereken például futtathatunk régi, Motorola processzoros alkalmazásokat (Windows alatt a WinUAE teszi ugyan ezt). De említhetném a sokak által ismert VirtualBoxot is. Ez utóbbi segítségével az intézeti Windowsos laptopra telepítettem egy Linuxot. A géphez nincs rendszergazdai hozzáférésem, mert az IT nem engedi, de a virtuális Linuxhoz van.

Az egész hardver virtualizálása több erőforrást igényel, mintha csak egy operációs rendszert futtatnánk, de szerencsére van megoldás akkor is, ha csak a kernelt akarjuk virtualizálni. A Docker például kedvelt eszköz, pont ez a célja.

Könnyen összeállíthatjuk kedvenc szoftveres környezetünket, elküldhetjük másoknak és elfelejthetjük a telepítés során fellépő hibákat, mert a rendszer garantálja, hogy a csomagunkat használva mindenki ugyan azt kapja. Még webes szolgáltatások is vannak a csomagok tárolására.

Valamivel kevésbé flexibilis ugyan és nem is ez az eredeti célja, de a Conda is tartalmaz virtuális környezetek kezelésére parancsokat. A Conda igazi célja a csomagok egyszerű telepítése és frissítése, de a

conda create -n env
source activate env

létrehoz egy env nevű környezetet. Minden további parancs erre a környezetre fog vonatkozni. A Conda egyébként tartalmaz egy tisztán bioinformatikai csatornát biconda néven.

Szólj hozzá!

Címkék: amiga rendszergazda

Majdnem mindent az RNA-seq-ről (3.rész)

2016.11.27. 21:55 Travis.CG

Elérkeztünk az RNA-seq legvitatottabb lépéséhez, az illesztéshez. Bárkivel beszéltem eddig RNA-seq-ről, mindenkinek megvolt a jól bejáratott véleménye arról, hogy melyik szoftvert kell használni és ebben a kérdésben nem ismert irgalmat. De én elárulom a nagy titkot. Csak nektek, ingyen. De aztán ne adjátok tovább, mert még mások is tudni fogják:

Tök mindegy. Először is, hiába használunk egy rendkívül kifinomult illesztőprogramot, ami a readek 100%-t illeszti, ha utána a kvantifikálás során a felét eldobjuk. Hiába akarunk egy elképesztően gyors alkalmazást futtatni, ha nincs elég memóriánk. Végezetül a legfontosabb indok: ha két gén expressziója jelentősen eltér, meg fogjuk találni azt, bármilyen programot is használunk.

Természetesen az illesztőprogramok között van különbség, nézzük meg, mik ezek. Még egy fontos dolgot meg kell említeni, ez pedig a felhasznált referencia típusa. Illeszthetünk transzkriptómra vagy genomra. Ha transzkriptómra illesztünk, nem kell foglalkoznunk azokkal a readekkel, melyek átérik az intronokat, tehát a DNS illesztésnél megismert programokat nyugodtan használhatjuk, például a BWA-t. Amire ügyelni kell, hogy a transzkriptóm egy gén több splice variánsát tartalmazhatja, ezért a paramétereket úgy válasszuk meg, hogy korrekt módon kezeljük a több helyre illeszkedő readeket. Erre most nem térek ki.

Ha genomra illesztünk, a többszörösen illeszkedő readek kevesebb gondot jelentenek (paralóg és pszeudó géneket leszámítva), cserébe meg kell küzdeni az intronokon átnyúló readek problémájával.

Bowtie

Ez a program elég egyszerű, még az indeleket sem kezeli. Pont ezért szeretik a mikroRNS elemzéseknél, ahol 20-24 nukleotid hosszú szekvenciákat kell a genomra pakolni, de azt gyorsan. Hátránya, hogy nagyon nagy genomokat nem képes kezelni. Embernél még nincs gond, de a búza genom gondot okoz neki.

TopHat

Kicsit öregecske program, már eljárt felette az idő. Lassú is szegény. Csak a történelmi hűség kedvéért említem meg. Annak idején a Tuxedo pipeline része volt, de a STAR megjelenésével sokan lecserélték. Ha az illesztésen kívül fúziós fehérjéket is akarunk keresni, a TopHat fusion a mi eszközünk.

GSNAP

Az EBI-ban az egy sejtes csoportok kedvenc illesztője. Változatos módon paraméterezhető. Sebességben a STAR mögött végez, de kicsivel több readet illeszt annál. Saját futtatásaim alapján viszont úgy láttam, hogy a génekre illeszkedő readek száma alacsonyabb, valamint több olyan readet is illeszt, ami három exonon is átnyúlik. Pontos számokat nem tudok mondani és az is elképzelhető, hogy paraméter tuningolással a fals illesztések száma is csökkenthető. Összességében teljesen korrekt program, memória szükséglete a STAR töredéke. Soha ne futtassuk alapértelmezett beállításokkal, mert használhatatlan eredményt produkál. A readeket annyi módon illeszti, ahány módon csak tudja, ami a sebességére is hátrányosan hat. Az EBI-os srácok a következő paraméterekre esküsznek:

gsnapl -t 4 -A sam -B 5 -n 1 -Q -N 1 -D referencia_dir -d referencia_nev read1.fastq read2.fastq

STAR

Ez az illesztő igazán univerzális. Hihetetlenül gyors, viszont a memória éhsége óriási, ami többszálú alkalmazásnál tovább növekszik. A Sangerben ez az RNA-seq pipeline része. A fejlesztője olyan opciókat is adott a programhoz, hogy a TopHathez hasonló kimenetet produkál, ezért egy TopHat alapú rendszerben fájdalommentesen beilleszthető. Rá épül egy fúziós fehérje kereső algoritmus, a STAR-Fusion. Ha van elég memóriánk érdemes ezt használni. Fontos, hogy alapértelmezett módon futtatva a nem illeszkedő readeket eldobja, ami a minőségi mutatók meghatározásánál gondot okozhat. Egy igazán sokoldalú paraméterezés a következő:

STAR --runThreadN 12 --outSAMstrandField intronMotif --outFileNamePrefix sample --outSAMattributes NH HI NM MD AS XS --twopassMode Basic --outSAMunmapped Within --chimSegmentMin 12 --chimJunctionOverhangMin 12 --alignSJDBoverhangMin 10 --alignMatesGapMax 200000 --alignIntronMax 200000 --chimSegmentReadGapMax parameter 3 --alignSJstitchMismatchNmax 5 -1 5 5 --limitBAMsortRAM 31532137230 --outSAMtype BAM SortedByCoordinate --readFilesCommand zcat --genomeDir reference --readFilesIn reads1.fastq.gz reads2.fastq.gz

Ezek a paraméterek STAR-Fusion és TopHat kompatibilisek.

HISat

Az új trónkövetelő. Erőforrás igénye alacsony, sebessége elképesztő. Rá épül az új Tuxedo pipeline, ami azért hagy még némi kívánni valót maga után. A program képes közvetlenül használni az SRA-t. Nem kell azokat Fastq-vá konvertálni.

Szólj hozzá!

Címkék: bioinformatika

Nyerő páros

2016.11.20. 20:00 Travis.CG

Toby mindig meglepődött, ha a hülyeség váratlan helyen bukkant fel. Nem kellett volna neki. Negyvenkét évesen épp elég tapasztalata lehetett volna, hogy ne lepődjön meg olyan elemi dolgokon, mint, hogy vannak ostoba emberek.

Ez mégis csak a Broad Institute - gondolta magában. Ez egy hely, ahol a minőséget folyamatosan magasan tartják azzal, hogy mindenkinek be kell számolnia az eredményekről a ranglétra magasabb fokán álló embereknek. Ez pedig azt jelenti - okoskodott tovább Toby - hogy az arra érdemtelen embereket kiszelektálják. Egy molekuláris biológiával is foglalkozó tudományos intézetnél ez egyet kellene, hogy jelentsen az ostobaság eliminálásával.

Toby azért nem panaszkodhatott. Rengeteg brilliáns koponyával találkozott. Kollégái remek emberek voltak. Leszámítva Pault. Paul ugyanis munkája során mellőzött minden statisztikai eljárást és különböző Excel bűvészkedésekkel kereste a rákos mutációkat. Rendezgette az adatokat, kézzel eltávolított elemeket, melyek tapasztalata alapján "nem lehettek fontosak". Toby ezért igyekezett távol tartani magát tőle.

Most viszont Paul megtalálta és hozta az egyik haverját, Ulrichot is.

Toby elég sok expressziós adatot dolgozott fel élete során, ezért egy vizsgálathoz az ő segítségét kérték. Az elején minden rendben ment. Paul, Ulrich és az egyik PhD hallgatójuk, Grace meghívták egy megbeszélésre, ahol átbeszélték a kísérlet hátterét, a lehetséges feldolgozási lépéseket és felosztották a munkát. Ulrich határozott, kompetens személynek tűnt, aki értette a vizsgált betegség biológiai hátterét. Paul a megbeszélés alatt az Excellel játszott és büszkén mutogatta a nyers readszámokat, mint expressziós profilt, egészen addig, míg Toby fel nem világosította annak felesleges voltáról.

A megbeszélés után Grace rendszeresen felkereste Toby-t, hogy segítsen neki az analízis egyes lépéseinél. Gyorsan elsajátította az ismereteket, nem kellett neki kétszer elmondani semmit. Sőt, még Toby is ellesett egy-két R fogást. Grace néha panaszkodott Ulrichra, hogy ennyire képtelen egy témára koncentrálni, de Toby betudta ezt az ősidők óta fennálló hallgató-témavezető viszálynak és nem foglalkozott vele.

De a hülyeség nem egy masszív tömeg. A hülyeség alaktalan gáz. Nem állítják meg falak, gátak. A hülyeség átszivárog mindenen. Megtalálja a legkisebb rést is és könyörtelenül keresztül furakszik. Tobyhoz is elkezdett szivárogni, méghozzá furcsa e-mailek formájában. Az első egy metilációs heatmap volt PNG formátumban. Ulrich azt tudakolta, a minták hierarchikus elrendezése mennyire hasonlít az expressziós minták elrendezéséhez. Ha a kérés nem lett volna már így is elég furcsa, de a két kísérlet alig tartalmazott közös elemeket. Mintha valaki azt kérdezte volna: itt ez a szép piros paradicsom. Mennyire hasonlít erre a sárga paprikára? Termés mindkettő, tehát hasonlítanak. Egyik gömböly, másik nem. Tehát nem hasonlítanak.

Toby is hasonló dilemmával nézett szembe.

Egy másik alkalommal Ulrich kooperációs partnere további expressziós eredményeket adott, de CPM normalizálva, mert ők azt tarották a legjobbnak. Toby TPM normalizálást használt, ahogy korábban egy megbeszélés során eldöntötték. Talán csak az egy betű különbségnek köszönhetően, de Ulrich megkérdezte, össze lehet-e hasonlítani a kettőt. Az e-mail alján Toby látta a korábbi levelezést az említett partnerrel, ahol Ulrich már feltette ezt a kérdést és a választ is látta, ahol elmagyarázták neki, miben más a kettő. Ennek ellenére tőle ugyan azt megkérdezte. Toby nagy levegőt vett és a lehető legudvariasabban elmagyarázhat, hogy nem lehet őket összehasonlítani, de ő szívesen megcsinálja a CPM normalizálást, ha azt kérik tőle. Igyekezett más szavakat és kifejezéseket használni, mint amit a levél alján látott, mert abban bízott, így talán könnyebben megértik mondandóját.

De Ulrichet nem lehetett ilyen könnyen lerázni. Még egyszer visszakérdezett: A CPM ugyan az, mint a TPM? Toby keze megállt a billentyűzet felett. Azért nem szerette a hülyéket, mert a sok magyarázás és értetlenkedés után azt gondolta, ő maga a hülye, amiért nem képes érthetően kifejezni magát. Mint, amikor mindenki röhög egy poénon, csak egyvalaki néz kérdő szemmel, hogy most mi a csattanó?

Toby végül azzal nyugtatta magát, hogy különböző entitások különböző nevet szoktak kapni. Tehát ha más a neve, akkor más tulajdonságai vannak. Mint ahogy az sem mindegy, ki fekszik a nászéjszakán mellettünk: Józsi vagy Rózsi. Itt is csak egy betű a különbség.

Egyik ebédnél épp a fenti dilemmán töprengett, amikor mellé ült Katerina. Már korábban is beszélgettek és ahogy az lenni szokott, nagyon hamar munkára terelődött a szó. Tobynak meglepetésként hatott a hír, hogy Katerina Ulrich post-docja és Paul munkatársa. A nő elmondta neki, hogy főnöket képtelen egy dologra koncentrálni, folyamatosan egymással össze nem függő vizsgálatokat kér.

- Legtöbbször a könyvtárba menekülök előle - mondta Katerina. Ha meglát, rögtön eszébe jut valami hülyeség. Ha pedig haladni akarok a saját témámmal, otthonról dolgozom.

- Paul miért nem menekül el?

- Pault nagyon kedveli Ulrich, mert bármilyen ötlete is van Ulrichnak, Paul pillanatok alatt választ tud adni a táblázatok módosításával. Bármit össze tud hasonlítani, bármit kielemez.

- De Paul legtöbb válaszának semmi értelme.

- Igen, de a legtöbb kérdésnek sincs, amit Ulrich feltesz.

Toby mégsem szerette ilyen rövid ismerettség után kijelenteni emberekről, hogy diettánsok. Talán csak arról van szó - vélekedett. - hogy nem tudták feldolgozni azt a váltást, amit a számítógépek megjelenése okozott a biológiában. Talán próbálják megérteni ezt a számáukra idegen közeget, csak nem megy nekik. Hiszen egy világbajnok sprintertől sem lehet elvárni, hogy lefussa a maratont. De nem is állnak rajthoz.

Szólj hozzá!

Címkék: irodalom

Kruskal-Wallis kisiparos

2016.11.14. 20:11 Travis.CG

Miután kiderült, hogy némi R szkripteléssel klikkelések ezreit tudom megspórolni, újabb búzás megbizatást kaptam. Maga a számítás nem volt bonyolult, hamar megvoltam vele. Utána viszont hosszú ideig nem történt semmi olyan, amihez a segítségem kellett volna.

A publikálás itt is nehezen ment. Talán három újságot is megjárt a kézirat, folyamatos átalakítást és újabb vizsgálatokat kellett végezni, de egyikhez sem kérték a segítségemet. Aztán a munkahely váltás még jobban elszigetelt a témától.

A helyzet pikantériája, hogy annyi új ismeretet tanultam itt, hogy ha most kellene megcsinálni a vizsgálatokat, sokkal többet tudnék a cikkhez hozzátenni. De ezen már nem lehet segíteni és a cikket sem lehet a végtelenségig csúsztatni, csak azért, mert van egy újabb ötletünk.

Mert ahhoz is érteni kell, hogy mikor hagyjunk abba egy munkát. Ha folyamatosan új kísérleteket csinálunk, új adatokat vonunk be, soha nem fogunk végezni és az a téves képzet alakul ki rólunk, hogy nem csinálunk semmit. Ez valahol igaz is, mert a hosszú munkával a beosztottak elunják magukat, az új projektek magasabb prioritást kapnak és végül minden ellaposodik, elhal. De akár a versenytársak is beelőzhetnek.

De ez a munka nem halt el, mert szerencsére nem hagyták elhalni. Nem úgy, mint más munkák, amikről azért nem írok, mert még reménykedem, hogy lesz belőlük valami. Vagy más kutatók, akik már 2014-ben beismerték egy intézet szintű összejövetelen, hogy már minden megvan a publikáláshoz, mégis további PhD hallgatókat emésztenek fel a kísérletek.

Szólj hozzá!

Címkék: publikáció

Túlprogramozás

2016.11.07. 00:47 Travis.CG

Egyszer volt, hol nem volt, valahol a CRT monitorok idején, de még a tapicskolós mobiltelefonok megjelenése előtt, a Napster fénykorában, volt egy zenelejátszó program, a WinAmp. Manapság, amikor gigabájtos tárak csücsülnek a zsebünkben, megmosolyogtató, hogy számítógépen tároltuk a zenéket, sőt még ott is játszottuk le őket (a prolik még CD-re is kiírták!), de nem volt más választásunk.

A WinAmp nagyszerű kis program volt, népszerűségben a Total Commanderrel (akkoriban Win Commander) vetekedett. Aztán történt valami rettenetes. Felütötte a fejét a túlprogramozás. A funkciók úgy potyogtak a kis szoftverbe, mint esőcseppek zápor idején. Kettőt pislogott a felhasználó és a program már filmeket is lejátszott, a külalak testre szabása pedig fontosabbá vált, mint maga a funkció. Az eszköz megszűnt az lenni, ami a célja volt és amiért szerették.

Ugyan ezt veszem észre az SRA Toolkit-el kapcsolatban is. A tárhely éhség csillapítására tömörítéseket vezettek be az NCBI-nál és elkészítették a kicsomagoló alkalmazást is. Kezdetben csak a Fastq konverzió volt a feladata, de mostanra egy felhő alapú, eloszott rendszer lett, ami a legegyszerűbb funkcióját is nyakatekert módon hajtja végre. A dokumentáció szerint a letöltött 180 MB nem müködöképes, szükséges hozzá a szerveren tárolt másik kódrészlet. Az, hogy milyen porton kommunikál, hogy esetleg megoldjuk a lehetséges hálózati problémákat, nem derül ki. A hibaüzenetek kriptikusak, nem szólnak semmit az aktuális problémáról, csak a virtuális adatbázis bejegyzésekről, amit valami hálózati alrendszeren keresztül akar végrehajtani. Ilyen szöveget manager meetingen mondanak, nem hibaüzenetekben.

A neten a legelterjedtebb megoldási forma: ne használd a programot, töltsd le a fastq-t az ENA-ról. Nekem nem volt szerencsém, a kérdéses szekvencia nem volt elérhető az említett formátumban. Kénytelen voltam megküzdeni az alkalmazással.

Habár elméletileg elég a szekvencia azonosítóját használni (az sra kiterjesztés nélkül megadott nevet azonosítónak tekinti a program és megpróbálja letölteni azt a szerverről), a gyakorlatban úgy tűnik a fastq-dump az egyetlen, amiből ez a funkció kimaradt. Miután letöltöttem mindent, folyamatosan időtúllépésre panaszkodott, mintha le akarna valamit tölteni. De ha már úgyis le akar valamit tölteni, letölthetné a szekvenciát is, nem? Mindegy, nem kell értelmet keresni egy túlprogramozott szoftverben.

Valami megmagyarázhatatlan csoda folytán a laptopomon működött minden. Csupán tárhely nem volt a szekvenciáknak. Ezért sshfs-el felcsatoltam a számítógép farm egyik gépét, majd oda mentettem mindent.

Később egy kolléga az NCBI embereit is bevonva kiderítette, hogy be kellett volna állítani a proxyt a vdb-config paranccsal. Csak azt nem értettem, máshol (git, wget, R, pip) miért nem kellett ilyesmit beállítani? Azok miért működnek nélküle? Bocsánat, megint értelmet keresek egy túlprogramozott szoftverben.

1 komment

Címkék: filozofálás bioinformatika

Majdnem mindent az RNA-seq-ről (2.rész)

2016.11.04. 01:55 Travis.CG

A szekvenálás minőségének meghatározása szinte teljesen megegyezik a DNS szekvenálásnál alkalmazott módszerekkel. Ez nem is meglepő, hiszen miután a minta előkészítés során az RNS-t átírtuk DNS-é, a gép ugyan úgy hajtja végre a szekvenálást. A FastQC ugyan úgy használható.

Az értékelés során viszont előfordulhat, hogy engedékenyebbek lehetünk. Ha kisRNS-eket szekvenálunk, az adaptor kontamináció nem hiba, a szekvenálás sajátosságából adódik. Egyszerűen a read hosszabb, mint a 20-24 nukleotidból álló molekula. Degradóm esetén úgyszintén.

De a felülreprezentált szekvenciák előfordulása sem feltétlenül hiba. Egy erősebben expresszálódó gén jelenlétét a program értelmezheti PCR hibának. Ha nem egy ismert adaptor a szekvencia, figyelmen kívül hagyhatjuk.

Attól, hogy a szekvencia maga jó, még nem jelenti azt, hogy értékelhető eredményt kapunk belőle. Illesztés után újabb minőségi ellenőrzést kell tartanunk. Különösen, ha egy sejtes szekvenálással van dolgunk. Erről lesz részletesebben is írás, most csak annyit mondok, ha a sejt feltárás során nem vagyunk elég óvatosak, az RNS bomlásnak indulhat és szekvenálás után csak annyit látunk, hogy kromoszómális génre alig, mitokondriális génre viszont töménytelen mennyiségű read illeszkedik. Ezen pedig a minta újraszekvenálása sem fog segíteni.

Érdemes tehát megnézni mennyi read esik arra a régióra, amit szekvenálni akarunk. KisRNS-eknél ezen kívül előszeretettel használják a méret eloszlásokat is. Egy sejtes szekvenálásnál több diagnosztikai ábrát is készítünk. Mivel nem ritka, hogy százas nagyságrendben szekvenálnak sejteket, ezért az X tengelyen az össz readszám szerepel, míg az Y tengelyen a százalékos mitokondriális génre illeszkedő readek száma vagy bármilyen génre illeszkedő readek aránya szerepel. Így viszonylag kevés ábrán sok mintát lehet áttekinteni. Ha az R-ben interaktív módon rajzoljuk ki a pontokat, klikkeléssel azonosíthatjuk a kiugró értékeket. Erre majd az egy sejtes posztban térek ki. Ha el nem felejtem.

Egy másik diagnosztikai eljárás a gén lefedettség (gene body coverage). Itt az összes génre illeszkedő lefedettséget ábrázolják, miután 100 nukleotid hosszúságúra normalizálják azokat. Ha bármelyik vég degradálásnak indul, ezen az ábrán könnyen észrevehető. Több, más statisztikával együtt az RSeqQC segítségével készíthetünk ilyen ábrákat.

A FastQC elég jó, de ha sok mintánk van, különböző, csak számunkra logikus könyvtár struktúrába rendezve, a FastQC használata elég macerás. Még akkor is, ha parancssorból is meghívható. Szerencsére a lusta elfoglalt embereknek fejlesztett multiQC megoldást nyújt erre.

Csupán egyetlen paramétert vár, a mintáinkat tartalmazó könyvtár nevét. A program rekurzívan bejárja az összes alkönyvtárat, a megtalált fájlok alapján megpróbálja kitalálni, milyen programokat futtattunk és HTML alapú összefoglalókat készít. Ennél egyszerűbb programot el sem lehet képzelni.

Szólj hozzá!

Címkék: bioinformatika

Majdnem mindent az RNA-seq-ről (1. rész)

2016.10.24. 01:46 Travis.CG

Már annyi RNA-seq adatot dolgoztam fel, hogy lassan én is elhiszem, hogy értek hozzá. Ez, és túláradó magabiztosságom együtt ezt a poszt sorozatot eredményezte, eredményezi.

Igyekszem valami rendszert felállítani, de annyi egymással összefüggő téma van, hogy akaratlanul lesznek átfedések. Azért remélem nem sűlyedünk a "Mindenféle dolog kusza összevisszasága" szintjére.

Az RNA-seq alapja az RNS szekvenálása. Először RNS-t izolálnak a mintából, ami lehet 1 sejt, néhány sejtes kolónia vagy még több sejtet tartalmazó minta. Ez "csak" olyan mértékben befolyásolja a bioinformatikai munkát, hogy mekkora amplifikációs hibával kell számolni. Mivel többféle RNS molekula létezik, az izolálás során megcélozhatunk bizonyos molekula típust és szekvenálhatunk mRNS-t, kisRNS-eket, riboszóma RNS-t, stb. A továbbiakban elsősorban az mRNS szekvenálásról lesz szó, mivel (szerintem) ez a legelterjedtebb RNA-seq alkalmazás.

Az mRNS-t a poliA vég segítségével viszonylag egyszerű kigyűjteni. A könyvtár készítés többi lépéséről nem írnék, mert ezt mások sokkal jobban tudják nálam, csupán egy részt emelnék ki, ami az analízist befolyásolhatja, ez pedig az irány specifikus (strand specific) kit alkalmazása. Ez röviden annyit jelent, hogy a szekvenálás során kapott read orientáció összefügghet annak az mRNS-nek az orientációjával, amiből származik. Az átfedő antiszensz transzkriptek esetén pontosabban meghatározható az expresszió. Itt a Sangerben az esetek 98%-ban a read orientáció megegyezik a transzkript orientációjával (first strand) és a veterán bioinformatikusok között van, aki már hallott olyanról, hogy valaki ellentétes irányú kitet használt (second strand).

Szemben a DNS szekvenálással, ahol a lefedettség jóval egyenletesebb, különböző transzkriptek lefedettsége eltérő lehet. Gyakran felmerülő kérdés, milyen mélységben szekvenáljuk mintáinkat? Természetesen attól függ, mire keressük a választ, de az Encode konzorcium ajánlása jó kiindulási alap. Ők egy standard emberi differenciál expressziós vizsgálathoz 30 millió readet elégnek tartanak, alacsonyan expresszálódó transzkriptek vizsgálata esetén 100-200 millió readet ajánlanak.

Ugyancsak gyakori vitakérdés az alkalmazni kívánt read hossza. Ugyan csak az analízistől függ. Ha csak gén szinten vagyunk kíváncsiak az expressziós különbségekre, akkor elég lehet a rövidebb méret is. Izoforma variánsok detektálása és referencia genommal nem rendelkező élőlények esetén a "hosszabb jobb" elv érvényesül.

Végezetül álljon itt néhány link, ahol nálam részletesebben mutatják be ezt a technológiát:

https://www.youtube.com/watch?v=0e1zWjgZODc

https://www.youtube.com/watch?v=Ji9nFCYl7Bk

http://rnaseq.uoregon.edu/

https://github.com/griffithlab/rnaseq_tutorial/wiki

Szólj hozzá!

Címkék: bioinformatika

Rejtett bioinformatikusok

2016.10.19. 01:25 Travis.CG

Aki álláshirdetések útján akar bioinformatikust találni, nem jár sikerrel. Azzal a furcsa érzéssel ér véget a keresés, hogy talán nincs is Magyarországon bioinformatikus. De ez nem igaz. Egyszerűen csak rossz a módszer. A Hidegháború idején sem úgy keresték az alvó KGB (vagy a másik oldalon a CIA) ügynököket, hogy feladtak egy hirdetést. A macsó filmekből ismert módszer sem válik be:

- Hogyan találjam meg?
- Sehogy, majd ő talál meg téged.

De ez nem jelenti azt, hogy nem lehet megtalálni őket. Mint ahogy a lámpa fénye is odavonzza az éjjeli rovarokat, úgy egy megfelelő csali kivetése után azt vesszük észre, hogy bioinformatikusok özönlenek minden felől. De mi lehet megfelelő csali egy bioinformatikusnak? Egy meetup!

Az internetnek hála máris tobzódhatunk a bioinformatikusok között, mint kisgyerek a labdamedencében. A tagok profilját átnézve senki ne lepődjön meg, ha nem talál kapcsolatot szekvencia feldolgozással, proteomikával vagy bármilyen olyasmivel, ami például ebben a blogban is előfordul. Ezek az emberek értik a dolgukat, hogyan maradjanak rejtve. Néhány embert akár még egy Excelt használó managerrel is össze lehetne keverni. Micsoda álca!

De most lefüleltük őket! Vége a játéknak!

1 komment

Címkék: filozofálás

Cseppet sem objektíven: Function 2016

2016.10.02. 02:15 Travis.CG

Már a második Function-t hagyom ki. Lassan már elvonási tüneteim lesznek. A kommentek nagyon visszafogottak voltak. Korábban bármilyen jó is volt a party, egyre-másra jelentek meg a negatív kritikák olyan egetrengetően fontos dolgokról, mint például a szponzorok megtapsolása. Idén semmi ilyet nem olvastam, aminek két oka lehet: vagy tényleg annyira jó volt a szervezés, hogy még a finnyás látogatók sem találtak semmi kifogásolni valót, vagy egyszerűen felnőtt a közönség. De nézzük meg, a látogatók mivel járultak hozzá a party színvonalához.

Zene

A zenék közül az Acid Blast vitte nálam a prímet. A szerzőről úgy rémlik még soha nem hallottam. Remélem a hetedik hely nem vette el a kedvét a további komponálástól/mixeléstől. Ha már a pörgős számoknál tartunk, Teo szerzeményét is meg kell említeni. A jól ismert stílust és tempót hamar felismertem, ötödik helyezése meglepett.

Grafikák

Ismét egy party alibi produkciók nélkül. Még a rangsor végére jutott képek esetén is az volt az érzésem, hogy az alkotók dolgoztak vele. Elárulok egy titkot. Amikor végignézem egy party anyagát, nem nézem ki készítette a képet, sőt a címét sem. Ha nem értem, mit látok, megnézem a címét és csak legvégül, mikor már az összes képet megnéztem, akkor rendelem hozzá a szerzőt. Persze, csak ha tetszik a kép. Néha már a kidolgozottság vagy a téma alapján felismerem az alkotót, de idén nagyon melléfogtam. Dorcy képéről simán azt gondoltam, hogy Unreal készítette. Unreal alkotása viszont enyhe deja-vu érzést keltett bennem, noha máig nem sikerült megfejtenem ennek okát.

Wild/Animáció

A két animáció szerintem gyenge volt. Az volt a - vélhetően túlságosan is magabiztos - érzésem, hogy ha nagyon felszívom maga, megcsinálom valós időben mindkettőt. A nyertes Raspberry Pi demó viszont fenomenális volt. Klasszikus elemekből építkezett, mégsem volt unalmas. Blueghost úgy tűnik megtalálta a neki leginkább fekvő platformot és minden tudásával azon van, hogy a végletekig kiaknázza annak lehetőségeit.

256b intró

Ezt a kategóriát külön tárgyalom a többi intrótól, mert egyrészt igen népes volt, másreszt elég kevés partyn fordul elő. Panaszra nem lehet ok. Volt szimulátor, attraktor, raytrace is. Rrola nyertes intrója a régi Linuxos képernyő pihentetőket idézi, természetesen jóval kisebb méretben. A második és harmadik, de még a negyedik helyezettnek sem kell szégyenkeznie, azok is legalább annyira jók voltak.

Intrók

Csak egy 64k intró volt, a Conspiracytól. A másik induló a kategóriában annyira gyenge volt, hogy nem is érdemes szót vesztegetni rá. Musk ennél sokkal jobbat tud. De visszatérve a nyertes alkotásra, a 2006-ban debütált és ikonikussá vált Chaos theory egyfajta újragondolása volt. Szándékosan nem használtam a remix szót, mert a jelenetek nem koppintásai voltak az elődnek. Körülbelül olyan kapcsolatban lehetnek, mint amilyen kapcsolatban az Unforgiven és az Unforgiven 2 a Metallicatól. Filmes témában nem tudok jó hasonlatot. Habár elismerem a Chaos theory érdemeit, a stílus nem az én világom. A Function-ös kiadás szép emléket állít a nagy elődnek.

A 4k vonalon viszonlag széles volt a spektrum. Voltak egyszerűbbek és kevésbé egyszerűek. A no xxit a Menger szivacsaival rögtön belopta magát a szívembe. Teljesen korrekt munka, megérdemelten nyert.

Demók

A nyertes demó egy vicces produkció aktuálpolitikai szatíra, de a lamer demóknál komolyabb technikai háttérrel. Személy szerint nekem nem jött be. Véleményem szerint a The experiment volt a legjobban kivitelezett alkotás. Volt egy kis történet is, amit könnyen lehetett értelmezni, az effektek csodaszépek voltak, kerek egészet alkotott minden. Végezetül ott volt a Gargaj Alternatív Demócsapat (The Adjective) alkotása. Kétszer néztem meg egymás után, ami elég ritkán esik meg velem. Azt hiszem, értem, miről szól, vagy legalábbis érteni vélem. A külső és belső világ konfliktusáról szól, ahol az egyén igyekszik megteremteni a belső békét, magában, mélyen, miközben a külvilág fokozatosan igyekszik behatolni és lerombolni mindent. De a végén a kamerák és mikrofonok mintha azt sugallnák, hogy mindezt egy médiaszereplő éli meg. Hmm, nagyon érdekes. Ennek kellett volna nyernie, még akkor is, ha a látványvilág nem olyan kiforrott.

Meg kell még említeni az utolsó helyezettet, ami a cseppet sem vidám Sosincs vége után egy kicsit megnyugtatja az embert. A Superior mind pozitív üzeneteket hordoz, kicsit propaganda-szerű, de nem bántó mértékben. Nálam kifagyott a vége, de talán lesz egy végső változat.

Szólj hozzá!

Címkék: demoscene

Úttörő munka

2016.09.26. 01:11 Travis.CG

Legfrissebb megjelent publikációnk igazi fejes ugrás az ismeretlenbe, mert a plazmidok és azok funkcionális elemeinek a keresése közben olyan módszerrel dolgoztunk, ami nem csak, hogy kiforratlan, de azon kívül, hogy "tök baró", nem is tudtunk semmit. Igen, a MinION szekvenálóról van szó.

Mint arról már beszámoltam, két csoport is csatlakozott a MinION Access Programhoz (MAP), aminek keretében kütyüket kaptunk. A csoport azt remélte, hogy egy transzpozon elemekkel átitatott megaplazmidot a hosszú readekkel megszekvenálnak és feljavítják az Illumina readekkel összerakott scaffoldokat.

Nem volt sok probléma, leszámítva a könyvtár előkészítési protokolt, a flowcell-t, a szekvenálót, a DNS-t, a basecall szoftvert, az Oxford Nanopore ügyfélszolgálatot és a tényt, hogy a munka kezdetén egyetlen olyan alkalmazás sem volt, amit MinION-ra terveztek volna. Ennek ellenére belevágtunk és a többi MAP taggal együtt próbáltuk használni a szerkezetet.

Tényleg élveztem a MinION-al való munkát, annak ellenére, hogy igazából egyetlen innovatív fejlesztéssel sem járultam hozzá a közösség munkájához, sőt az igazi szekvenálási sikereket is akkor érte el a csoport, miután eljöttem. (Nehogy messzemenő következtetéseket vonjon le bárki is!) Talán abban mérhető az én szerepem, hogy igyekeztem meggyőzni mindenkit, hogy ne lépjen ki a programból és a sorozatos kudarcok ellenére is fizessék ki az újabb flowcelleket.

De ezekből a kudarcokból tanultuk meg például, hogy a flowcellek nem tárolhatóak hónapokon át. Erről az igen fontos tényről például egyetlen blogbejegyzés vagy dokumentáció sem volt.

Ami viszont nagyon jó volt a projektben (a kütyüvel való játszadozás mellett), hogy bioinformatikusként úgy éreztem, a kutatás része vagyok, nem csupán egy gomba. Nem csak én adtam eredményeket nekik, ők is megosztották velem, amit találtak. Folyamatosan ment a kommunikáció, mindig tisztában voltam a projekt alakulásával.

Igyekeztünk meglovagolni a MinION hype-ot, amikor minden cikk magas impaktú lapban jelent meg, még akkor is, ha semmi értelmesről nem szólt, de sajnos a folyamatos kudarcok ezt nem tették lehetővé. De azért akkor is örülök neki, hogy van bizonyíték, hogy dolgoztam a szerkezettel.

Szólj hozzá!

Címkék: publikáció nanopore

Rendszer építés

2016.09.24. 07:51 Travis.CG

Majd három évvel az előző verzió megjelenése után itt az új Slackware. El is határoztam, hogy frissítem a rendszert. Ez egyáltalán nem volt egyszerű. Először is az optikai meghajtóm SATA kábele nem működik valami jól, valószínű a számítógép külföldre költöztetése során megsérült. Mivel nem egy komoly tétel, ezért a "majd később szerzek egyet" kategóriába esett, vagyis mindig találtam valami indokot, amivel elodáztam a beszerzést.

A másik probléma, hogy van egy csomó olyan fájl a gépemen, ami arra nem érdemes, hogy letöröljem, de annyira nem is fontos, hogy biztonsági mentést csináljak. Sehova nem tudtam őket átmásolni. Végezetül a Slackware rendszerem egy RAID 0-án csücsül (a boot meg egy RAID 1-n), ami teszi a dolgát, nem kellene bolygatni.

Először csináltam a gyökérbe egy biztonsági másolatot a HOME könyvtárról és még néhány configurációs állományról, bemásoltam a Slackware ISO-t is, majd ezeket kivéve letöröltem mindent. Most már nem volt visszaút. A telepítő lemezen volt egy telepítő boot fájl, azt USB meghajtóra másoltam, majd elindítottam róla a rendszert.

A telepítő gond nélkül elindult. Mivel a partícionálás már megvolt, ezért rögtön a rendszer telepítésére ugrottam. Mivel a csomagok az ISO-n voltak, azt felcsatoltam:

mount slackware.iso /mnt/dvd -o loop -t iso9660

Megadtam a RAID 0-t gyökér partíciónak, a RAID 1-t bootnak (utóbbit formáztam is), majd jött a csomagok kijelölése. Erre számtalan opció van. Le lehet tölteni netről, kereshetem pendrive-n, vagy előre felcsatolt könyvtárban. Itt volt néhány felesleges köröm, mert a doksi szerint elég a csatolási pontot megadni (/mnt/dvd az én esetemben), de ez nem igaz, a könyvtár helye kell. (/mnt/dvd/slackware64) A rendszer persze nem ad semmilyen hibaüzenetet, de gyanús volt, hogy a csomagok felmásolása kb. 4 másodpercet vett igénybe.

Miután erre rájöttem, a rendszer szépen települt. Még a Lilo felpakolása sem volt gond, bár automatikusan nem ment, kézzel kellett megadni a Linux és a boot loader helyét.

A telepítő nem piszkálta a félretett fájlokat, azokat az első indítás után visszamásoltam a HOME-ba, és kész is voltam.

Eddig az NVidia meghajtó telepítése sem okozott gondot, de az új Slackware is beállt a sorba és a nouveau driverrel érkezik. Ez a két meghajtó program nagyon nem szereti egymást. Szerencsére az NVidia telepítője szépen kikapcsolta.

Az egyetlen dolog, amivel gondom volt, a CUDA SDK telepítése. Kiderült, hogy a C++ fordító túl új, vissza kellene mennem a 4.9-es verzióra. Ahol ugye csomagkezelő van, ott ez nem probléma, de Slackware alatt egy kezdetleges van, függőség kezelés nélkül. Ezért úgy döntöttem, kézzel fordítok egy GCC-t. Olyat még úgysem csináltam.

Egy fordító fordítása érdekes folyamat. Három lépésből áll. Először kell fordítani egy GCC-t (a rendszeren található GCC-vel), majd az a GCC lefordítja önmagát, és ez a másodszor fordított GCC ismét lefordítja önmagát. Közben összehasonlítja, hogy a másodszor és harmadszor fordított fordító ugyan az-e. Végül lefordítja a könyvtárakat.

Először a 4.7-el próbálkoztam, de az hibával elszállt. Végül egy 4.9-t fordítottam, mert gondoltam az verzió számban közelebb van a telepített GCC-hez. Jó másfél órát izmolt a gép, mire mindent lefordított. Az új GCC-t az /usr/local/gcc-4.9 könyvtárba pakoltam, és a verziószámot beállítottam suffixként, hogy meg tudjam különböztetni ezt a sok fordítót. A PATH környezeti változót pedig úgy állítottam be, hogy először ebben a könyvtárban keresse a binárisokat. Ezzel az egyszerű trükkel az nvcc előbb találja meg a neki megfelelő fordítóprogramot. Utána már a CUDA példaprogramok lefordítása sem okozott problémát.

Eddig egyszerűen megúsztam, hogy konfigurálnom kelljen a wi-fit, mert minden telepítőt leszedtem a munkahelyemen és hazavittem. Amire viszont most készültem, ahhoz a net elengedhetetlen volt.

A kernel szerencsére felismerte az USB-s wi-fi adaptert, a megfelelő modult is betöltötte. Az /etc/wpa_supplicant.conf fájlba fel kell vinni a kívánt hálózat adatait, az itt leírtak szerint. El kell indítani a wpa_supplicant programot, hogy csatlakozni tudjon. El kell indítani a dhcpcd wlan0, hogy kapjunk IP-t és már netezhetünk is.

Meg kell jegyezni, hogy igazán felemelő olyan környezetben dolgozni, ahol nem telefonál haza minden kis hülye alkalmazás, hogy adatokat gyűjtsön a felhasználói élmény növelése céljából. Mivel 1 Mb-es netem van, érezhető a különbség az Ubuntu és Slackware között (a Windows 10-ről inkább nem is beszélek).

Így már nekiláthatok a Torch telepítésének. A GitHubról leszedett kód igyekszik telepíteni a függőségeket. Van is egy szkript, ami Ubuntu, Fedora, ArchLinux, CentOS, elementary OS alatt fel is tesz mindent. Slackware persze nem támogatott, de ez nem is baj. Személy szerint ezért kedvelem ezt a disztribúciót, mert alapból benne van minden, ami egy fejlesztőnek kell. Megnéztem a szkriptet és két olyan függőségre volt csak szükség, ami nincs telepítve. Az egyik az OpenBLAS, a másik az iPython. Az OpenBLAS a Torch lelke, abban vannak a mátrix műveletekhez szükséges optimalizált könyvtárak. GitHubról simán felment. Az iPython viszont nem értettem, miért kell. Rövid gondolkodás után úgy döntöttem, az bizonyára csak akkor kell, ha valaki Pythonból akarja használni a programot, ezért azt nem telepítettem.

A Torch gond nélkül lefordult. Mivel ez is egyfajta programozói környezet, számtalan csomag van hozzá, amit külön kell telepíteni. A luarocks install fel is pakolt mindent, amit akartam, kivéve a cutorch csomagot, ami a CUDA támogatás lett volna. Valami oknál fogva megtalálta az új GCC-t, és nem a 4.9-t, ami a CUDA fordítónak kell. Böngésztem a netet megodás után kutatva, de mindenki csak azt javasolta, hogy szimlinkek kusza halmazával oldjam meg a problémát. Az nem jó. Aztán egy kósza gondolattól vezérelve létrehoztam két környezeti változót: CC és CPP, amit megfeleltettem a régi GCC-nek:

export CC=gcc-4.9.0; export CPP=g++-4.9.0

A telepítőt újra futtatva már nem volt több gond. Ha minden jól megy, egy új tematikával fog bővülni a blog...

Szólj hozzá!

Címkék: rendszergazda

Én megmondtam

2016.09.15. 00:18 Travis.CG

A blog lassan hat éve megy és eddig egyetlen konstans, mit sem változó üzenete van. Mégsem fogadjátok meg. Fogadjunk, hogy most is ott van a gépeteken. Megbújik, mint egy vírus, egy parazita. Talán azt gondoljátok, ezt, vagy azt a fájlt igazán megnyithatom vele, abból nem lesz baj.

Tévedtek! Soha nem szabad elindítani. Gondolni sem szabad rá, hogy elindítjátok. Sőt, arra sem szabad gondolni, hogy arra gondoltok, elindítjátok. Ez csak ahhoz vezet, hogy végül elindítjátok.

Most azt hiszitek viccelek. Szinte hallom, ahogy felsóhajtotok: már megint jön az Excel utálat. Hát már soha nem lesz vége? A válaszom: nem. Nem lesz vége, amíg meg nem szabadul az emberiség ettől a ragálytól.

Talán valami viccesre vártok, de csak szomorú dolgokat tudok írni. Ha arra a sok nyomorúságra gondolok, ami mind ennek a programnak köszönhető, sírni tudnék.

Még mindig nem hisztek nekem, de talán másoknak hinni fogtok. Például nekik. Ők is azt hitték, megnyitni egy táblázatos fájlt Excellel nem okoz galibát. Aztán a sok génnév átalakult dátummá. Sajnos ők még a cikk megírása idején a megvilágosodás korai szakaszában jártak és egy Linux shell szkripttel akarták orvosolni a problémát, ami elég furcsa megoldás. Hiszen ki fog átmenni Linuxra, csak azért, hogy Excel kompatibilissá alakítson egy táblázatot. A megoldás jóval egyszerűbb: Uninstall Excel.

Talán arra gondoltok, számolgatni még lehet vele. Tényleg? Ez a program még arra is alkalmatlan. Ez semmi más, mint a négyzetrácsos papír digitális megfelelője. De egy négyzetrácsos papíron legalább tudni lehet, mi van. Egy Excel táblában soha nem tudhatod, mi van. Semmi nem kényszerít rá, hogy egy munkalapon egy táblázat legyen és az emberek tudják ezt. Táblázat-szörnyetegeket alkotnak, amire a színezés teszi rá a koronát.

A színezés nem csak a színtévesztők és színvakok legnagyobb ellensége, hanem minden olyan embernek, aki adatokkal dolgozik. A színezésnek nincs értéke, nem adattípus, csak egy vizuális nyalóka, amire semmi további analízis nem építhető.

De nem csak a színezés, hanem a használhatatlan diagram típusok tömkelege is ott csücsül, értékes erőforrásokat elvonva a géptől. Évek óta köztudott, hogy a kördiagram rossz. Mégsem tud eltűnni az Excelből. Igaz, az Excel sem tud eltűnni.

De most ennek a cikknek hála talán egyre többen fognak ráeszmélni, hogy azokat a szoftvereket kell használni, amik az adott feladatra készültek, nem a hasznavehetetlen vackokat, amiket a merevlemez bugyraiból előbányászunk.

Szólj hozzá!

Címkék: bioinformatika

Mutáció keresés rákos mintákban

2016.09.10. 00:10 Travis.CG

SNP-k és más variációk keresése rákos szekvenciákban egy kicsit eltér a "hagyományos" variációk keresésétől. Először is, a ráksejtek genetikai anyaga más, mint a gazdaszervezeté, másrészt egyes ráktípusok, még ha fenotípusosan homogénnek tűnnek is, poliklonálisak lehetnek. Kicsit olyan, mintha egy populációt szekvenálnánk, de az egyedek DNS-e nem ekvimoláris mennyiségben lenne összekeverve.

Szerencsére számtalan eszköz áll rendelkezésünkre, hogy megtaláljuk ezeket az eltéréseket. A bemutatásra kerülő programokat használtam, vagy legalábbis megpróbáltam használni, de ezen a folyamatosan fejlődő területen akadnak még más kincsek is. Az összes bemutatásra kerülő alkalmazásnak van egy közös pontja, hogy bemenetnek nem csak a tumort, hanem az egészséges, úgynevezett normál mintát is kérik.

SNP-k, indelek

Crisp

A program korábbi verzióját gond nélkül használtam populációs minták vizsgálatára. A fordítása nem volt nehéz, de utána folyton sig faultolt. Nem kutattam a hiba okát, csak letöröltem.

LoFreq

Ezzel a programmal sem volt szerencsém. Már a fordításnál elakadtam. Itt sem jártam a dolgok végére, az rm parancs fájdalommentesen orvosolta a problémát.

deepSNV

Ez az R program fordult és futott. Viszont pontosan nulla variációt talált. Mivel a fejlesztő a szomszédban csoportvezető (EBI), elmentem hozzá konzultációra. A program akkor a leghatásosabb, ha legalább 100-as coverage van. Nekem egy kicsit kevesebb van. Egy másik potenciális gyengesége a programnak, hogy kis számú target esetén működik. Legalábbis minél nagyobb a vizsgált régió, a többszörös teszt korrekció annál alacsonyabb p-értéknél vág. Moritz szerint ennek ellenére exome adatokon is működnie kellene, nekem nem működött. És a cikk is csak egy kis régión teszteli. A program a nagy mélységgel szekvenált mintákban akkor is képes megtalálni a mutációkat, ha azok poliklonálisak. Ezen eltérések könnyen összetéveszthetőek a szekvenálási hibákkal, ezért a normál mintát használja annak megállapítására, milyen gyakran téveszt a szekvenáló.

Caveman

A programot házon belül fejlesztették. Egy TCGA konferencián, ahol a nagy intézetek algoritmusait hasonlították össze, ez a program találta a legkevesebb fals pozitív variációt. Sajnos nem is talál meg mindent, ebben a Broad Institute alkalmazása ebben jobb. Az erőforrás éhsége pedig óriási. A pipelinunk 32 szálon futtatja a mintákon, hogy időben legyen eredmény. (Szálanként 3GB memória kell neki.) Egy külsős partner megpróbálta saját gépre telepíteni, két hétig ment a levelezés, mert mindig volt valami gubanc. (Helpdeskesként pont belecsúsztam én is a beszélgetésbe. Végül kiderült, hogy egy 250 GB-os BAM fájlon akarta futtatni.) Szóval nem rossz a cucc, de parancssorból nem akarom futtatni.

Pindel

A Caveman csak SNP-ket keres. Indel keresésre a Pindelt használjuk. Ezt sem futtattam még parancssorból. Nálunk a kutatók nagyon óvatosan kezelik az általa nyújtott eredményeket, mert elég magas a fals pozitív találati aránya, de ez a legtöbb indel kereső alkalmazásra igaz.

Mutect

Ez a program nagyon szimpatikus volt. Először is működött, ami a sok frusztráció után igazán üdítő volt. Viszonylag gyors, nem kell neki sok erőforrás, megtalál mindent, de a fent említett konferencián azt találták, hogy nagyon sok téves találatot is visszaad. Egy másik negatívum, hogy az általa produkált kimenet egy táblázat, nem VCF, mint amit egy variáció kereső programnál elvárnánk.

Struktúrális variációk

Delly2

Ezt a programot is nagyon kedvelem. Telepítése elég egyszerű, futtatása egyértelmű. Bemenete BAM fájl, kimenete VCF, nem kényes a bemeneti fájlra A fórumok szerint transzlokációk keresése kegyetlenül lassú rajta, én ilyet nem tapasztaltam. Mindegyik variáció típusra közel azonos sebességgel futott. Az első futás eredményét minden esetben érdemes szűrni (a programban van erre beépített opció), mert azokat a variációkat is visszaadja, ami a normál mintában is előfordul. Nem teljesen világos számomra, miért kell külön futtatni a szűrést, mert így egy genomon 10-szer kell lefuttatni. Az összes variáció típushoz külön kapcsoló van, plusz a szűrés.

Brass

Ez is része a pipeline-nak. Webes felület ide vagy oda, nekem ezt a programot még nem sikerült futtatni. Ha épp nem a bemeneti adat volt alkalmatlan a programnak, akkor a farm nem fogadott új kérést, vagy új release volt, amitől kinyírták az épp futó elemzéseket. De az ötlet egészen jó benne. Először a read párok méret eltérését veszi alapul, majd a nem illeszkedő readek alapján a Velvet segítségével új kontigokat gyárt és azokat teszteli, mint lehetséges inszerciókat. A futási ideje ennek megfelelően hosszú.

Szólj hozzá!

Címkék: bioinformatika

Cseppet sem objektíven: Assembly 2016

2016.09.02. 00:10 Travis.CG

A digitális szubkultúra Mekkájában ismét izzottak a GPU-k, villogtak a pixelek és a elektronikus zene a Földet is megrengette. De a padlót mindenképp. Idén a nagy nevek nem képviseltették magukat. Nem volt Fairlight, Panda Cube, Conspiracy. Vajon ez hogyan befolyásolta a party színvonalát? Rövidesen megtudjátok.

Zene

Idén is voltak remek zenék minden kategóriában. Egyeseknek még a 90 perces alkotási korlát sem volt akadály, hogy tempós zenét készítsen. Rayjan lehet, hogy új kedvenc lesz Almost című száma alapján. Aikapallo már régi motorosnak számít az Assembly történetében, követem is munkásságát. Ha a party közönsége idén nem is díjazta erőfeszítéseit, ezen blog szerény keretei között megkapja az elismerést. A szokásos rockos alapot most japános hangzással dobta fel.

Grafikák

Ebben a kategóriában is elég színvonalas munkák kerültek bemutatásra. Szerencsére elég kevés compo filler volt, így szerintem még a hátul végzettek is megéremlik, hogy legalább egy pillantást vessünk a képeikre. A posztba a fotó kompó nyertes képét linkelem.

Játékok

Ennyi pihent agyú játékot már régen láttam. A szimulátor láz már lecsengett a nagyvilágban, amikor értelmetlen küldetéseket kell végigjátszani kecskével, kenyérrel vagy más pihent agyú objektummal, demoscener fronton még továbbra sem unják a témát. De két szauna szimulátor egy compón? Ez azért sok, még akkor is, ha Finnországban vagyunk.

Videók

Fájdalom, de az idei film felhozatal gyenge volt. A HBC csupán egy tech-demót adott le, nem release-t. A szellemes videó számomra nem volt vicces. A 20 éves korosztály valószínűleg nem is érti a Superman-poént benne, legalábbis a kommentek alapján erre következtetek. A fenébe, öregszem.

Oldschool demók

Itt megint éreztem az idő vas fogát. A releasek többsége PC volt, nem Amiga, C64 vagy más 8 bites gép. A nyertes demó nagyon szépen kivitelezett alkotás, le a kalappal előtte. A többiek, még a két Amigas entry sem hagyott mély nyomot bennem.

Intrók

Két kategória is volt, ahol a csökkenő méretkorlát egyre nagyobb kihívást jelentett a résztvevőknek. A 64k valami miatt hiányzott. A 4k sem volt annyira erős, mint máskor. Persze az Outcast a maga egyszerűségével igazán látványos volt, de nem volt meg az igazi 4k érzés. Az 1k már más tészta volt, ettől az ember nem vár sokat, ezért bármit kap, elcsodálkozik. A Fulcrum intrója azért tetszett, mert ha nem is volt története, nagyon közel állt valamihez, amit akár sztorinak is felfoghatok. Más szavakkal szólva ebbe bele tudnék magyarázni valami összefüggést.

Amit még szeretnék kiemelni, hogy voltak Linuxos intrók. Ez külön öröm volt számomra. Még az 1k-k között is akadt!

Demók

Kicsit felemás érzésem volt a helyezéseket és a pouet.net kommenteket olvasva. Esztétikailag az első négy helyezett szerintem nem szégyenkezhet. A Pyrotech demót sokan leszólták, hogy random jelenetek vannak egymás után, ami igaz. De szerintem az első helyezett sem sokkal jobb. Két jelenet váltakozik, majd a végén egy laza kapcsolattal összehozzák őket, amitől mindenki elalél. Technikai szempontból viszont a Pyrotech igenis magasabban áll, az Unreal Engine-t használó első helyezett, még akkor is, ha valószínűleg semmit nem módosítottak a kódon az eltelt évek során. Érdekes, máskor mindig mekkora probléma volt, ha játék engine-el készítenek el valamit. Most meg a saját fejlesztésű motort szólta le a közönség. Változik a világ, kérem. Én bátorításnak azért is a Pyrotech demót linkelem be. Az Unreal maszatot meg keresse meg, aki akarja :-)

Összegzés

Azt hiszem, amit itt láttunk, egy átalakulási folyamat köztes állapota. Egyfelől az igazán profik már a saját üzletükkel foglalkoznak, nem érnek rá demókat kódolni. Akik eddig a második vonalban voltak, most előrébb kerültek. A kódolás szerepe háttérbe szorult, még azt is csak kevesen kifogásolták, hogy a második helyezett csapat egy fél Qt keretrendszert pakolt a demó mellé. Harmadrészt a nagy nevekkel együtt a nagy multú platformok is visszavonultak, hiszen a fiatalabbak gyerekkorát nem az Amiga határozta meg, hanem a korai PC-k.

Végezetül itt a link a teljes anyagra.

Szólj hozzá!

Címkék: demoscene