Az élet kódjai

Két év után újra meglátogattam a régi melóhelyemet és ismét találkoztam Pannal. Bizonyára ő is nagyon hiányolt, mert csak az én kedvemért előadott egy egyszemélyes performance-t.

Épp egy volt kolléganővel beszélgettem, akinek a gépére R-t kellett volna telepíteni. A beszélgetést folyamatosan hatalmas sóhajok kísérték Pan részéről, innen tudhattam, mennyire nehéz is ez a folyamat. Épp a családtagokról volt szó, amikor Pan hangosan közbevágott.

- Nem megy a telepítés. Hibát ír ki.

- Mi a hibaüzenet? - tudakoltam megértően.

- Nem tudom, nagyon sok hibát ír ki.

Teljesen korrekt. Ha nagyon sok hibaüzenetünk van, egyiket sem olvassuk el, hiszen az időpocsékolás. A legtöbb hülye fejlesztő úgyis csak viccből rakja ezeket a programokba.

- Mi az utolsó hibaüzenet? - kérdeztem ártatlanul. Nem kaptam választ. Pan ujjai erősebben koppantak a billentyűzeten. Talán azt remélte tőle, hogy a számítógép megérti, az így begépelt parancsokat komolyabban kell venni.

Közben másra terelődött a szó, mivel Pan tovább dolgozott. De mikor ismét elkezdődtek a sóhajok, sejtettem, hogy újabb nehézséggel találta szembe magát.

- Nincs hálózat - kommentálta hangosan.

- Az egész intézetben vagy csak a gépen? - tudakoltam. Elvégre, ha tönkre vágjuk a hálózatot, akkor csináljuk rendesen, ne álljunk meg egy gépnél.

A helyzet tovább eszkalálódott. A hálózat elvesztése után egyszer csak felkiáltott:

- Semmi sem működik!

- Kapcsold ki a gépet, mielőtt rászabadul a világra! - javasoltam. Nem volt vevő a megjegyzésemre. Kérte a rendszergazdai jelszót. Mikor megkapta, rögtön be is gépelte.

- Nem működik.

- Próbáld meg num lock nélkül - javasolta neki kolléganőm. A dolog működhetett, mert Pan nem szólalt meg.

- Csináljak biztonsági mentést? - kérdezte viccesen a gép tulajdonosa. Akkor még nem gondolta, hogy ez később komoly lesz.

Pan tovább folytatta azt, amit abba kellett volna hagynia. Vannak, akiket néha meglátogat Bitmumus, de rájöttem, egyesek szimbiózisban élnek vele. Talán ő súgja rendszeresen Pan fülébe, hogy belégzés-kilégzés. Nem tudom, de abban a pillanatban biztos voltam benne, hogy Pan képtelen Bitmumus nélkül élni.

- Nem merem újraindítani a rendszert, mert félek, hogy nem tud bebootolni. Kéne csinálni egy biztonsági mentést.

- Nincs annyi tárhelyem.

- A rendszer frissítése félúton elakard, elment a hálózat. Be kellene fejezni a csomagok telepítést egy CD-ről, de azt nem tudom, hogyan kell - azzal Pan otthagyta a gépet és elment erősítésért.

Én is jobbnak láttam, ha elmegyek. Később megtudtam, még két napig dolgoztak a gépen, hogy használható legyen. Most kellene írnom valami tanúságot, valami pozitív dolgot, amiből mások tanulhatnak. Legalább annyit: gyerekek, ne drogozzatok, mert ilyenek lesztek. De még ez sem adatott meg nekem. Pan teljesen tiszta.

A kópiaszám változások azonosítása teljes genom szekvenálásból nem különösebben bonyolult. Rengeteg eszközt találni rá és elég jól működik. Többségében a lefedettség változását veszik alapul. Targetált szekvenálásnál (ide értve mindent, ami nem teljes genom szekvenálás) viszont a lefedettsége önmagában nem elég. A kívánt genomi terület kiválasztására alkalmazott protokoltól függően különböző hibákat vihetünk be a rendszerbe, aminek hatása van a lefedettségre.

Mit jelent mindez? Először is, más metodológiát kell használni, másrészt az eredmény sokkal megbízhatatlanabb. Mennyire? Nagyon.

Az intézetben a CNVKit-et használják a legtöbben, de az egyik kutató megkért, hogy használjam a CopywriteR-t, mert a kooperáló partnerek szerint az a legjobb. A projekt vezetője viszont - teljesen jogosan - tudni szerette volna, melyik módszer ad megbízhatóbb eredményt.

Az összehasonlítás alapjául egy korábbi, megközelítőleg 500 sejtvonalon elvégzett microarray szolgált, amit később megszekvenáltak. Egy egyszerű Pearson korrelációval megnéztük, melyik módszer ad jobb megoldást. A CopywriteR esetén az együttható értéke 0,1 volt, de a CNVKit sem teljesített fényesebben a maga 0,3-jával.

Az eredmény nem ért teljesen váratlanul, mert olvastam ezt a cikket. Ebben található a következő ábra:

Vegyük észre, hogy az ábrán a 0,5 a legmagasabb érték, amit egyetlen eszköz sem képes elérni. Mit jelent mindez? A megtalált CNV variációk több, mint fele fals pozitív! Ez egy őszinte cikk. Sokszor látni publikációkat csupa ragyogó értékkel, de mikor az ember maga kipróbálja az adott programot, csak szemetet kap vissza. Még az Excavator korábbi verziójának leírása is ilyen. Itt viszont nyoma sincs semmi ilyesminek. Az eredmények tükrözik a saját tapasztalatot.

Ezek alapján azt javaslom mindenkinek, aki valóban tudni szeretné, milyen kópiaszám változások vannak a mintáiban, futtasson egy alacsony lefedettségű teljes genom szekvenálást is.

Az interaktivitás hajnalán, még a szerepjátékok elterjedése előtt voltak a Kaland Játék Kockázat könyvek. A történetet olvasva időről időre kérdéseket tettek fel, hogyan folytatódjon a sztori és a megfelelő oldalra lapozva olvashattuk döntésünk következményét. Elméletileg a harcjeleneteknél dobókockával kellett volna némi bizonytalanságot (és ezzel együtt izgalmat) csempészni az események folyásába, de senkit nem ismertem, aki betartotta volna ezt a szabályt.

Személy szerint én utáltam ezeket a könyveket, mert a döntésnek csak az illúzióját adták. Emlékszem például, hogy az egyik kaland során valami titkos szektát fedeztem fel egy régi, elhagyatott ház pincéjében. A csuhás nézők közé elvegyülve egy ember áldozatnak voltam a szemtanúja. A könyv fel is tette a kérdést: ha meg akarod menteni a lányt, lapozz X oldalra, ha végignézed a halálát, lapozz Y-ra. Természetesen a megmentést választottam. A mentő akció abból állt, hogy ordítva az oltárra ugrottam, felfedve magamat. A túlerő legyűrt és végül egy döntést hozhattam: álló vagy ülő ketrecbe zárjanak halálomig. A könyv még nagyképűen oda is írta nekem: "mégis, hogy képzelted, hogy megmentheted?". Biztosan nem úgy, hogy ordítva odaugrok. Le akartam kapcsolni a villanyt, hogy a sötét megzavarja a ceremóniát. Be akartam indítani a tűzjelzőt vagy én magam tüzet gyújtani. Kihívni a rendőrséget, katasztrófa védelmet. Túszul ejteni a szekta vezetőjét.

Minden ilyen zsákuca után leírták az ikonikus mondatot: kalandod itt véget ér. Ez volt a legtöbbet olvasott mondat, könyvtől függetlenül.

Most nekem is véget ér egy kalandom. Mikor ezt olvassátok, már nem leszek a Sanger alkalmzásában, hanem utazom vissza Magyarországra. A családom már egy ideje nincs itt, csak én varrom el a szálakat. Próbálom eladni az ocsmány bútorokat, amiket már én is használtan vettem, javítom a bérelt lakásban általunk okozott károkat.

Azt hiszem, az egyik legjobb döntésem ebben az életben, hogy eljöttem ide. Az időjárás kiszámíthatatlan, a kaja förtelmes. Nem lehet egy jót kirándulni, mert minden nyomorult zöld terület körbe van kerítve, legfeljebb másfél méteres ösvényeken lehet csak közlekedni. A legtöbb beszélgetés a helyiekkel felületes és semmit mondó, kimerül az időjárásban. De a meló kárpótolt mindenért. Nem azt éreztem, hogy bármi is visszafog, hogy közém és az eredmény közé állna. Gyakorlatilag a limitáló tényezők saját korlátaim voltak, hogy nem ismerek elég matematikai modellt, amivel az adatokat kiértékelhetem, nem látom át az összefüggést vagy nincs meg az a programozói tudásom, hogy hatékonyabb kódot írjak és ne kelljen 200 évet várni az eredményre.

Nem is tudom, hol olvastam, hogy a kommandósok brutális kiképzésének nem az a célja, hogy a kiképzők kiélhessék szadista hajlamaikat, hanem, hogy az egyén megismerje saját korlátait. Mi az, amit meg tud csinálni és mi az, amit nem. Ez pedig szerintem fontos lenne mindenkinek. Nem egy bioinformatikust/programozót láttam, akik visszajelzés vagy komoly kihívás hiányában azt hitték, hogy ők a szakma csúcsa.

A másik hasznos dolog, amit itt láttam, az információ akadály nélküli áramlása. A sok idegesítő meeting egyik kellemes mellékhatása, hogy nyugodtan fel lehetett vetni bármilyen problémát, rögtön mondtak rá megoldási javaslatot. Nem láttam olyan titkolózást, mint máshol, ahol szintén eljöttek segítséget kérni, de közben nem mondták el az igazi problémát, csak úgy körülírták azt. Mint amikor úgy beszélünk az orvossal, hogy "a barátomnak van egy olyan baja...". Nonszensz, felesleges és nem hatékony.

Természetesen a tudomány élvonalában maradni nem lehet áldozatok nélkül. Ha egy csoport probléma felvetése, módszerei nem voltak elég előre mutatóak, szívbaj nélkül kigyomlálták őket. Mikor a rák genom projekt vezetője kijelentette, hogy megtalálták az összes gént, ami a tumorok 50%-ban előfordul, az egész program átalakult. Néhány klinikai onkológus el is kezdett szállingózni innen.

A másik véglet, amit az egyetemen láttam. Egyes tanszékek tökéletesen elvoltak saját világukban. Konkurencia, elvárások nem voltak. Aki oda bekerült, onnan ment nyugdíjba, akkor is, ha csak a kötelező oktatást csinálta meg. A publikálás pedig kimerült néhány konferencia kiadványban megjelent összefoglalónál. Lehet szidni az elitizmust, de ez utóbbi szerintem sokkal rosszabb.

Lehet szomorkodni a múlton, de minden kaland vége egyben egy újnak a kezdete. Közhely, de ettől még igaz. A kötelék az intézettel még nem szakadt meg, mostantól konzultáns leszek és távmunkában folytatom, amit elkezdtem. Időről-időre visszatérek és beszélek az emberekkel. A konzultáns egyébként is egy remek név. Kellően titokzatos és úgy hangzik, mintha értenék is valamihez.

Ha nem számoljuk az egereket (modell organizmus), szúnyogokat (malária csoportok kedvenc állata), különböző élősködőket (parazitológia csoportok), akkor is sokféle állattal találkozhatunk az intézet területén.

A képet Stefancsik Raymond készítette a COSMIC csoportból. Ez a sas komoly munkát végez. Hetente egyszer látogatja az intézetet és röpköd egyet az épületek körül. A cél, hogy a galambok és varjúk kártevő munkáját megszűntessék. Ha végzett, visszarepül a gazdájához.

Az intézethez tartozik egy természetvédelmi terület is, aminek az állományát rendszeresen felmérik. Megtalálhatóak itt a vizisiklók, békák, különböző madarak és pillangók. Én a pillangók megfigyelésében veszek részt. Ez abból áll, hogy keddenként, ha az idő megfelelő, ebédidőben kimegyünk a területre és összeszámoljuk a pillangókat. A többiek már nagyon profik, néha a repülési stílusból tudják, hogy milyen lepkéről van szó. Én csak néhányat ismerek fel, a többinél meg az "ott van valami" felkiáltással másokra hagyom a beazonosítást.

Egy C betűs lepke (comma). A következő képen egy kis rókalepke (small tortoiseshell) van.

A Sulston épület néhány ablakából rá lehet látni egy mesterséges tóra, ahol vadkacsák és szürke lúdak úszkálnak. Szép látvány, de mikor kimennek a gyepre, akkor elaknásítják azt.

Van még egy élőlény, aki nagyon szeret az intézet területén lenni, de jelenléte néha problémás. Ő Qiuncy, a macska. Quincy a közeli faluban él, de képtelen ellenállni a tudománynak, igaz csak az ebédlő teraszán és más naptól felhevített területen műveli azt. Fekve. Rendszeresen megpróbál belógni valamelyik épületbe. A biztonságiakat szerencsére alaposan kiképezték, így időben fellépnek, ha Tom Cruise-t megszégyenítő módon belóg. A potenciális humán kollaboránsokat köremailben térítik jobb belátásra.

Quincy újabb beszivárgási kísérlete a Morgan épületbe.

Még egyetlen QBPartyn sem voltam, de követem az eseményeket. A beszámolók és releasek alapján számomra is úgy tűnik, a QBParty egyre jobb lesz. Szemezgessünk minden kategóriából egy kicsit.

Grafika

A Retro Time című kép enyhe deja-vu érzést váltott ki belőlem. Nem azért, mert a szobámat idézte, hanem mert hasonló témájú képet mintha láttam volna, csak Amigaval. Valljuk be, a C64 joystick ide jobban illik, mint egy PC mellé. Természetesen nem mehetek el szó nélkül a hím Saturnia pyri mellett. Egészen gyönyörű.

Intrók

A Paradyze 20 egy retro PC-s hangulatot idéző intro, ahol greetingeltek minket. Igaz, le kellett lassítanom YouTube-on a demót, hogy lássam, de tényleg ott vagyunk. The specificationról nehéz eldönteni, hogy egy kijavítatlan bugot vagy absztrakt látványvilágot látunk. Nem tudom eldönteni. A Crystalline lord pedig határozottan hangulatos, ahogy a hasábok emberré állnak össze.

A legjobb produkciókat mégis 256b-ban kell keresni. A Torus inside a nagyobb méretkorlátos intrók világát hozza el. Logót és két jelenetet mutat be, ami igen impozáns ebben a kategóriában. A Mind evolves fraktál és zenél egyszerre, nálam nagyon bejött.

Demók

Az oldschool kategória csupán jelképesen képviseltette magát. A vicces vonalat ismét a Tesco Gazdaságos Demócsapat vitte a Kacsák és kockák demójukkal. A Minden Gargaj 2-nek is beillő Gargaj 9001-t teljes értetlenséggel fogadtam. Ez az a fajta humor, ami sör nélkül nem vicces. Manapság divatos emlegetni, hogy az AI elveszi (vagy el fogja venni) ennek vagy annak az embercsoportnak a munkáját. A Los Angeles Lamers már most eljutott arra a szintre, hogy egy nem túl okos mesterséges intelligenciával hasonló stílusú releaseket lehetne gyártani. A Too wierd to Die egy színpadi produkció volt, amit a SceneSat felvételéről néztem meg, de nem tudom megmondani, mit is láttam. Olyan volt, mint egy David Lynch film: többféle értelmezése is lehet és nem biztos, hogy a látott kép bármit is jelent. Amit láttam, az egy világító szemű druida, aki maga tákolta elektronikus hangszeren játszott. Az Abstr'One lézershowja már egy más dimenziót képviselt. Xerxes zenéjével igen kellemesre sikeredett.

Ha pedig a technikai felkészültségnél tartunk, akkor nem mehetünk el szó nélkül a Rebels impozáns demója, a Dark Side mellett sem. Environment mappelt golyók ezrei vagy tízezrei mozogtak részecske rendszerként és alkottak felületeket, formákat.

Nincs két egyforma szekvenálás. A kapott read mennyiség futásról-futásra változik. Ha csupán összeszámoljuk a vizsgált egységre (génre, transzkriptre, exonra) eső readeket, nem tudjuk összehasonlítani az expressziót más szekvenálásokkal. Szükség van olyan eljárásokra, ahol a szekvenálásból eredő, technikai jellegű különbségeket eltűntetjük. Ez a normalizálás.

Normalizálás után minden különbség, amit találunk, feltételezhetően a biológiai rendszerek különbségeiből adódik. Mint oly sok problémára a bioinformatikában, a normalizálásra is többféle megoldás létezik. Szerencsére nem kell választanunk a különféle eljárások közül. A legtöbb alkalmazás eleve elkötelezi magát egyik vagy másik módszer mellett, tehát ha programot választunk, azzal eleve meghatározzuk, milyen normalizálást fogunk használni.

A legjobb szándék ellenére sem tudom összeszedni az összes létező eljárást, de megpróbálok annyit leírni, amennyivel csak találkoztam. A másik fontos megjegyzés, hogy egy-egy módszer fejlődik az idők során, nem biztos, hogy úgy implementálták azt az alkalmazott programokban, ahogy én itt leírom, de az elv nagyon hasonló.

CPM

Ez a legegyszerűbb eljárás, miRNS-ek esetén ezt használják. A génre (transzkriptre, exonra) eső readszámot elosztják a teljes readszámmal, majd megszorozzák egymillióval, hogy ne kelljen túl kicsi számokkal dolgozni. Innen ered a neve is (count per million).

FPKM/RPKM

Ez nem egy eljárás, hanem egy eljárás család. A kiszámítás módja úgy kezdődik, mint a CPM esetén, tehát egymillió readre normalizálnak, de a teljes readszám mellett a gén hosszára és a read hosszára is normalizálnak. A különbség, hogy miként határozzák meg a read hosszát (a read pár mindkét tagját, vagy csak egyik tagját számolják) és a gén hosszát (teljes gén hossz, effektív hosszúság). A kezdetek kezdetén nem foglalkoztak a readek méretével, csak a gén teljes hosszával osztottak. Később rájöttek, hogy a hosszabb readekből kevesebb illeszkedhet a vizsgált egységre, ezért gén hosszából levonták a readek hosszát. (Úgy is mondhatnánk, a gén hossza helyett azzal számoltak, hogy hány pozícióra illeszkedhet egy read, anélkül, hogy lelógna.) Később tovább módosították a metódust, mert a PacBio szekvenálás miatt a readek hosszabbak lehetnek, mint egy gén.

TPM

A TPM esetén a számolás nagyon hasonló az FPKM-hez, de számolás sorrendje fordított. Először normalizálnak a gén hosszára és csak másodsorban a readek mennyiségére. Miért teszik ezt? Bármilyen szekvenálást is veszünk, a gének TPM normalizált értékének összege azonos lesz. Ha például sejtvonalakat szekvenálunk nagy mennyiségben, akkor nem tudunk hagyományos differenciál expressziót számolni (nincs kontroll, kezelés, a mindent-mindennel összehasonlítást pedig nehéz kiértékelni), de tudunk klaszterezni és kereshetünk mintázatokat. Ezen analízis pontossága szerintem kérdéses, de kivitelezhető és a TPM normalizálás a legjobb választás ilyen esetben.

TMM

Ezen eljárás során abból a feltételezésből indulunk ki, hogy a gének nagy tömege nem mutat differenciál expressziót. Tehát ha vesszük az összes gén expressziójának mediánját, akkor attól magasabb vagy alacsonyabb értékek egy bizonyos százalékáról kijelenthetjük, hogy nem mutat expressziós változást. Ezen gének expresszióját felhasználva kiszámolhatunk egy szorzó faktort, amivel az expressziókat átválthatjuk egy másik minta expressziós értékére. Mivel egy kisérlet több mintát is tartalmazhat, önkényesen kijelölnek egy referencia mintát, majd ehhez számolják ki a szorzó faktort. A módszer nagyon hatékony, de mint említettem akkor, ha a gének egy része nem mutat differenciál expressziót. Ha tehát egy normál egeret akarunk hasonlítani egy genetikailag módosított, mutagénnek kezelt, stresszelt állattal, akkor számíthatunk rá, hogy kevésbé lesz hatékony. A másik potenciális vagy inkább filozófiai eredetű probléma, hogy a referencia nem esik át semmilyen módosításon. Tehát ha a módszerből bármilyen eltérés adódik, akkor ez a minta mentes lesz tőle.

DESeq

Ennek a normalizálásnak nincs külön neve, de mivel a DESeq és a DESeq2 ezt használja, rendszerint így hivatkoznak rá. Nagyon hasonlít a TMM-hez, de ahelyett, hogy önkényesen jelölne ki egy mintát referenciának, mesterségesen kreál egyet. Vagyis minden minta kap szorzó faktort.

TC/UQ/Med

Ez a három módszer nagyon hasonló. Az egy génre eső readszámot elosztják egy számmal, majd megszorozzák az összes minta teljes readszámának átlagával. Hogy mi ez a szám, az a módszertől függ. TC (total count) esetén ez az adott minta teljes readszáma. UQ (upper quartile) esetén a nullától különböző readszámok felső kvartilise, míg Med (median) esetén ez a közép érték lesz (ugyan csak a nullánál nagyobb read számokat véve alapul).

SCRAN

Ez szintén nem egy módszer neve, hanem egy programcsomag egy sejtes RNA-seq elemzéshez, de tartalmaz egy normalizálási eljárást is, direkt ehhez a fajta szekvenáláshoz. A fenti módszerek legtöbbje nem használható egy sejtes adatok esetén, mert sok génről egyszerűen nem keletkezik read. (Bár nekem egy EBI-os fickó azt mondta, nyugodtan használjam a CPM-t) Ez a módszer az úgynevezett spike-in kontrollok használatával igyekszik orvosolni a problémát. A spike-in egy mesterséges RNS szekvencia, amit ismert koncentrációban keverünk a mintákhoz. Mivel mesterséges, a róla képződő readek csak ide illeszkednek és mivel ismert koncentrációban adjuk hozzá, a különbség csak is technikai lehet. Ezzel természetesen még nem oldódott meg a probléma teljesen, mert egy sejtes szekvenálásnál a sejt ciklust szabályozó gének különböző mértékben aktívak, de ez a csomag ezt is megpróbálja orvosolni.

Összefoglalás

Megpróbáltam minél több normalizálási módszert összeszedni, de a lista nem teljes. Újabb és újabb (és bonyolultabb) módszerek jelennek meg, rengeteg cikk hasonlítgatja a különböző módszereket, különböző eredménnyel. Egy dologban minden cikk egyetért: normalizálni kell. Nem tudom, melyik a legjobb, az egyetlen tanács, amit adhatok: elsősorban programcsomagot kell választani. Ha olyan programot választunk, ami a legtöbb igényünket kielégíti, támogatott, sokan használják, akkor nem kapunk túl rossz eredményeket és a kéziratba nem fognak belekötni a bírálók (legalábbis a módszerekbe nem. Vagy nem nagyon.)

A csoportunkban igen intenzív mikroszkópos munka folyik. A szekvenálás, amit elemzek, csak egy része a kísérleteknek. A másik része a szövetek vagy sejtek időbeli változásának nyomon követése mikroszkópos képeken.

A legtöbb munkát a kutatók meg tudják oldani maguk is, de néha elkél nekik a segítség. Csak röviden említem, hogy sejtosztódásnál az utódsejtek nem azokos arányban osztódnak tovább. Az egyik utód sejt nem fog tovább osztódni. Ez biztosítja, hogy a szövet képes legyen fenntartani egy állandó állapotot. Ha viszont felborul ez az egyensúly, - márpedig ráknál pont ez történik - akkor a szövet burjánzásnak indul.

Az egyik projekt tehát, hogy figyelik, hogyan, miként változik a sejtosztódás. Ezt úgy csinálják, hogy egy ember ül a képernyő elött, nézi a képeket és klikkel. Úgyhogy egy csoport megbeszélésen a kutató nekünk szegezte a kérdést, tudunk-e valami módszert, amivel meggyorsíthatjuk a mitózis keresést.

Természetesen azt mondtam, hogy tudok. Az ötletem az volt, hogy betanítok egy neurális hálót, hogy ismerje fel a sejt osztódást.

Első lépésben szükségem volt egy tréning adatszettre. Mivel a munkatársam már végigszenvedte ezt, örömmel megosztotta velem az eredményt. Sajnos elég volt rá egy rövid pillantást vetni, hogy kiderüljön, nekem ez nem lesz jó. Maga a mitózis elég szépen felismerhető. Az egyik képen még egy sejt van, a következőn pedig kettő (sőt, néhány kivételes alkalommal három!). A kapott adatban viszont munkatársam néha a mitózis elejét jelölte be, néha a végét. Néha az egyik utód sejtet jelölte meg, mint pozíciót, náha a szülő sejtet. Ezek különböző kombinációiból állt az adat.

A másik dolog, ami miatt ez nem volt megfelelő tréning adatnak, az a negatív adatok hiánya. A hatékony tanításhoz nem csak azt kell beadni a neurális hálónak, mi a tényleges mitózis, hanem azt is, mi az, ami biztosan nem az.

Ezt rendbe kellett szedni. Először írtam egy elég primitív programot, amivel a kurzor billetyűkkel a képkockák között tudtam váltani, jobb egérgombbal pozitív adatot, ballal a negatív adatot definiálhattam. Kis kör jelölte, amit a kollégám azonotított. Esc-re kilépett, mint egy demo :-) Ezzel elég gyorsan újra definiálhattam az adatokat.

A második lépés a neurális háló tanítása volt. Először is a mikroszkópos képeket be kellett olvasni:

vector<Mat> frames;
imreadmulti("pic.tif", frames);

Létre kellett hozni a mátrixokat. Összesen négy mátrixra volt szükségem. Kettő a tréning adatnak, kettő a teszt adatnak. OpenCV-ben egy mátrix az értékeket tartalmazza, amivel tanítjuk a neurális hálónkat, egy pedig az eredményt, amit kapni szeretnénk. A teszt adat pontosan ugyan ilyen felépítésű lesz, de azzal más terveim voltak.

Mit fognak tartalmazni a mátrixok? Először is, a pixelek intenzitását. A vizsgált kép 40x40-es, ami nem tűnik nagynak, de 1600 pixelt tartalmaz. Ez még csak egy kép. Ha a mitózis előtti állapotot is bele akarjuk rakni, az újabb 1600 pixel lesz. Ha van 600 adatsorunk, a mátrix 3200x600 méretű lesz (vagy 600x3200, ízlés kérdése, az OpenCV mindkettőt elfogadja).

Az eredmény az én esetemben egy oszlop volt, 600 sorral (minden tréning adathoz egy). Az érték pedig -1, ha nem történt mitózis, 1, ha történt. A neten sok példaprogram a 0-1 számokat használja. Én úgy tapasztaltam, a -1 - 1 jobb eredményt ad.

Mat train_data(600, 3200, CV_32FC1);
Mat train_label(600, 1, CV_32FC1);

Ezeket a mátrixokat feltöltöttem adattal. A teszt adatszettet ugyan így készítettem elő. Kellett még néhány paraméter, például meddig tanuljon az algoritmus, mikor álljon le.

TermCriteria termCrit = TermCriteria(
        TermCriteria::Type::MAX_ITER,
        500,
        0.0001
        );

Ez azt jelenti, hogy max 500 ciklus fog lefutni vagy akkor áll meg, ha az újabb adatsor tanulásával az eredmény csak picit változik. Ezt a két értéket nyugodtan lehet változtatni. Javaslat: amíg a program a hibakeresés, tesztelés fázsban van, érdemes a ezeket az értékeket használni, mert a program gyorsan le fog futni. De amint készen vagyunk és a háló hatékonyságát nézzük, az 500-t akár 10 millióra is emelhetjük, a másik paraméter meg még alacsonyabb lehet.

Mat layers = Mat(4, 1, CV_16U);
layers.row(0) = Scalar(3200);
layers.row(1) = Scalar(800);
layers.row(2) = Scalar(800);
layers.row(3) = Scalar(1);

Ez lesz a hálózatunk topológiája. 3200 bemeneti neuron, két rejtett réteg egyenként 800 neuronnal, majd 1 kimeneti réteg. Igazából nincs arra egzakt szabály, mennyi köztes réteg legyen és azok mennyi neuront tartalmazzanak. Ami szabály van, azok sokkal több matematikai tudást igényelnek, mint ami nekem van. A próba-szerencse módszer sokkal célravezetőbb volt.

Ptr<TrainData> td = TrainData::create(train_data, SampleTypes::ROW_SAMPLE, train_label);

Itt csak összepárosítottam az adatot és az elvárt eredményt, valamint megmondtam a rendszernek, hogyan értelmezze a mátrixokat. Jelen esetben soronként.

Ptr<ANN_MLP> mlp = ANN_MLP::create();
mlp->setTrainMethod(ANN_MLP::TrainingMethods::BACKPROP, 0.1, 0.1);
mlp->setTermCriteria(termCrit);
mlp->setLayerSizes(layers);
mlp->setActivationFunction(ANN_MLP::ActivationFunctions::SIGMOID_SYM, 1, 1);
mlp->train(td);

Végül összeállítottam a neurális hálót és betanítottam. Ezen a ponton pár dolgot kiemelnék. A setActivationFunction-t érdemes a setLayerSizes után meghívni, különben értelmezhetetlen lesz az eredmény. Ha a setActivationFunction-t SIGMOID_SYM-re állítjuk, az utána lévő két paramétert is állítsuk be, mert alapértelmezetten 0-k és szintén furcsa, nehezen felderíthető hibát okoznak. (Egy teljes hétvégém erre ment rá, hogy rájöjjek.)

Kész a tanítás, mennyire jó a rendszer? Most volt szükségem a teszt adatszettre.

Mat response;
mlp->predict(test_data, response);

A response változó pont olyan dimenziójú, mint a train_label. Csupán össze kell hasonlítani a test_data-hoz tartozó eredménnyel és máris megtudjuk. Ne várjunk teljes hasonlóságot! Én -1 és 1-t adtam meg, de e két érték között bármilyen értéket kaphatunk, attól függően, a rendszer mennyire "biztos" az eredményben. Ha egynél nagyobb vagy -1-nél kisebb számot kapunk, valószínűleg a neurális hálónk nem tanult jól. Adjunk neki több adatot, ha tudunk, vagy játszunk a paraméterekkel.

Nekem sokáig nem adott rendes eredményt a program. Már ott tartottam, hogy előadást tartok a módszerről, de a program még mindig nem működött. (Prediktálás után nan-t kaptam. nan=not a number) Végül az előadás után egy héttel jöttem rá, hogy a tréning adat teljesen rossz. Egy nagyon amatőr kasztolási hibát ejtettem, amitől csupa szeméttel tanítottam a hálót. Természetes, hogy hülyeséget adott vissza.

A poszt írásának pillanatában 72%-os hatékonysággal működik, amivel nem fogok gépi tanulás versenyeket nyerni, de arra jó lesz, hogy lerövidítse a klikkelések számát.

Már régen tervbe vettem, hogy elmegyek a cambridge-i számítógép múzeumba. Most végre lehetőségem is nyílt rá. Nem volt könnyű megtalálni, mert egy raktár bázis szélén volt és csak annyit mutattak a táblák, hogy menjek be a sok bádog épület közé, azon belül nem sok jelző tábla volt.

Azért aki nem adja fel, megtalálja. A legérdekesebb része az egész múzeumnak, hogy a gépek működnek és kipróbálhatóak. A legtöbb gép előtt szék van, már betöltöttek egy játékot, amivel azonnal beszippanthat a retró hangulat. Aki pedig emlékszik még a használatukra, további lemezeket, kazettákat talál a gépek mellett.

Az első teremben volt kiállítva a Megaprocesszor. Természetesen erre is írtak játékot, egy tetriszt, amit hatalmas bumfordi gombokkal lehetett vezérelni. Bevallom, ez volt a legunalmasabb játék, amit valaha játszottam. A processzor olyan lassú, hogy képtelenség rendesen irányítani a blokkokat. De nem is ezért építették.

A második teremben telepedtek le a gamerek. Nem tudom, mivel játszottak, csak a lövéseket és puffanásokat hallottam. Ugyancsak ebben a teremben voltak kiállítva az Acorn modelljei. Két sorban csak BBC Microk voltak, felhasználói kézikönyvekkel. Nagyjából 10 percig tanulmányoztam a könyvet, majd nekiláttam kódolni az egyiken. Az első gépen nem működött az O betű, ezért nem tudtam begépelni a gonosz GOTO utasítást. Átültem egy másikhoz, ahol már nem volt ilyen problémám. Ez lett az eredmény:

A régi szép idők, mikor még StackOverflow nélkül is lehetett kódolni, csupán egy kézikönyv segítségével.

A harmadik terem volt az igazi kánaán. Itt volt kiállítva a C64, C+4, Atarik, egy Amiga 500 (James Pondal). Felsorolni is reménytelen, mennyi gép volt ott. Olyan gépekkel játszottam, amiről nem is hallottam korábban, pedig a demoscenén belül találkoztam pár antik darabbal. (Tatung Einstein demóról még nem hallottam, nem találtam. Úgyhogy itt a nagy lehetőség!)

A kiállított C64-en egyébként egy crackelt International Karate futott, megcsodálhattam egy régi introt is, miután betöltődött a játék.

Egyébként az Acorn hasonló utat járt be, mint a Commodore, legalábbis, ha a számítógép generációk fejlődését nézzük. Először ők is egy 64k-s modellt adtak ki, majd jött a "mindent egybeépítünk" modellek, amint az Amiga 500, végül a PC dobozok majmolása. Viszont nem maradt utána akkora felhasználói bázis, akik életbe tartották volna. Ha csak a demoscenét nézem, még az Amstrad CPC-nek is nagyobb tábora van, mint az Acornak.

Itt is voltak kiállítva konzolok, időrendben. Nem vagyok egy játékos típus, ezért ez a vonal kimaradt az életemből. Meglepő látni, hogyan fejlődött a technika, miközben az irányítás szinte semmit nem változott. Ennek ellenére mikor újra kellett indítani egy játékot, nem tudtam, hogy az X, A, O közül mit kell nyomni.

Az Apple korai modelljeit is meg lehetett csodálni. Ezek mondjuk kellemetlen emlékeket idéztek fel bennem, mert annak idején, PhD hallgató koromban a főnökömnek hála egy Power Machintossal "dolgozhattam".

De a Silicon Graphics kiállított munkaállomásai gyorsan elfeledtették a múlt sötét árnyait. Azok nagyon tetszettek. De ezek már Unix munkaállomások voltak, nem okozott gondot, hogy használjam őket. Egy látogató még Hello Worldöt is fordított rá.

Persze nem minden kiállított termékkel lehetett játszani. Voltak gépek, amiket csak nézni szabadott. Egy szekcióban a telekommunikációs eszközök is voltak. Itt ért a második sokk. Az a telefon modell, amit mind a mai napig használok, kiállítási darab volt! Ott ült velem szemben! Ne szóljatok semmit, én is le tudom vonni a megfelelő következtetést.

Ha már ennyit emlegettem a demoscenét, tudni kell azt is, hogy egy tábla erejéig bizony arról is megemlékeztek a múzeumban. A korai PC-k között kiállítottak egy olyan darabot, ami már nem csak pittyegett, hanem dedikált hangkártya volt benne. Egy Gravis Ultrasound. A kis tábla említette, hogy mennyire népszerű volt a demoscenerek között. Sajnos a gép lefagyott, nem hallhattam a GUS-t működés közben.

Végezetül láthattam, hogyan fejlődtek a hordozható gépek. Úgy látszik a cipelhető számítógépekre már kezdetekben is elég nagy igény lehetet, mert rengeteg megoldás volt a problémára. Csak azt nem értem, miért kellett két floppy meghajtó mindegyikbe?

Még egy katonai modellt is sikerült szerezniük, amiről nem sok információjuk volt.

Eredetileg csak két órát terveztem, hogy maradok, de a programozás, a sok játék miatt észre sem vettem, hogy már négy órája számítógépekkel bohóckodok. Miután kijöttem, akkor éreztem csak, milyen éhes is vagyok.

Ha van mennyország, akkor az így néz ki. És ha van pokol, akkor az is, csak áram nélkül.

Kor Leó az Európai Parlament protokollszolgálatánál dolgozott asszisztensként. Munkája során hozzászokott a kifinomult és választékos élethez. Szerette is ezt a letisztult világot, hiszen az élet úgyis annyi szörnyűséget tartalmazott, jól esett neki, ha erről legalább nap közben nem szerzett tudomást. Elég volt, ha az esti híradások során szembesült vele.

Egy hónapja viszont más eseményre készült. Feleségével, Annával együtt nemsokára keresztszülők lesznek. Három és fél éves lányával, Editkével együtt, hármasban utaztak haza Brüsszelből a nagy eseményre. Magyarországon Anna szüleinél - Lajosnál és Mártánál - szálltak meg, a nagyszülők legnagyobb örömére, akik ismét elkényeztethették unokájukat.

A nagy eseményre mindenki a legjobb ruháját vette fel. Legalábbis az elérhető legjobbat. Leó sötétkék Luciano Barbera öltönyét vette fel. Anna egybe részes halvány sárga Guccit választott, míg lányukra egy vidám kockás ruhát adtak.

- Fél egyre kell a templomhoz érni, jobb lenne, ha sietnétek - jegyezte meg Lajos. Természetesen ez csak Mártának szólt, hiszen egyedül ő nem állt még készen.

- Még Editkére sem adtátok fel a kabátját - replikázott a nagymama - meg fog fázni. Ilyen időben nem lehet kabát nélkül kimenni!

Leó észrevett egy szürke, széles galléros gyerek kabátot. Anna hozhatta ki korábban. Márta visszarohant a WC-re, Leó ráadta a kabátot a gyerekre. Lajos az autó papírjait szedegette össze, Anna illatszerekkel vonta be magát. Editke begörbítette hátát, felhúzta karjait és trappolni kezdett:

- Én vagyok a sárkány! - kiáltotta.

- Márta, rád várunk! - kiáltotta Lajos. - Tíz perc múlva a templomnál kell lennünk - válaszra sem várva kilépett az ajtón és az udvaron keresztül a garázs felé indult. Editke megérezte a zavart az egyensúlyban:

- Papa, merre vagy!?

- Itt vagyok, kicsim. Kiállok az autóval.

Editke visítva rohant nagyapja után, mintha Papa azt jelentette volna be, hogy 10 hónapra Tűzföldre, Kalkuttába vagy más hasonló tájra megy. Anna és Leó sorra vették Editke kiegészítő felszerelését, hiszen egy gyerek rengeteg váratlan helyzetet tud okozni, ezekre nem árt felkészülni. Ital, hogy ne szomjazzon: megvan. Rágcsálni való, hogy ne éhezzen: megvan. Fröccsöntött műanyag bogár (szigorúan négy végtaggal hat helyett), hogy ne unatkozzon: megvan. WC ülőke, hátha a rágcsa és az ital gyorsabban teszi a dolgát: nincs meg.

- Kell a WC ülőke - jelentette ki Leó.

- Melyik legyen? - kérdezte Anna. Márta ugyanis, ha látta, hogy unokájának vettek valamit a szülei, ő is vett egy hasonló tárgyat, majd később megmutatta és kijelentette: ez sokkal jobb. Az idők során Editke nem szenvedett hiányt semmiben. Volt két rollere, két plüs bocija (akkor épp a boci volt a kedvence, csak bocis mesét lehetett mesélni, bocis tányérból kellett enni és plüs bocival aludni), két festék készlete, és természetesen két WC ülőkéje is.

- A miénk - mondta Leó a pragmatizmus és dac furcsa keverékével. Az ő darabjuk ugyanis még be volt csomagolva a reptéri túlélő csomagba és érkezésük óta ott is volt, nedves törlőkendővel és más szükséges kellékkel.

- Miért azt viszitek? - kérdezte Márta, aki közben kiért a WC-ből. Tegyétek el ezt. Ez sokkal jobb. Csak bele kell tenni egy szatyorba.

Anna Leóra nézett. Leó megadóan felemelte a kezét. Lajos közben kiállt az autóval. Editke rájött, hogy míg Papával volt, túlságosan eltávolodott Apától. Elkezdett visítva rohanni vissza a házba.

- Vegyél fel a nyakamba! - mondta a kislány, de Leó tudta, ez azt jelenti, hogy neki kell felvennie lányát. A ragozással még voltak gondok.

- Nem, kislányom, most nem lehet. Szép ruhában vagyunk, nem koszolhatjuk össze.

Editkét beszíjazták a gyerekülésbe, Márta bezárta a lakást, mindenki elfoglalta helyét az autóban, majd elindultak.

- El fogunk késni, már csak hét percünk van, hogy odaérjünk - kommentálta Márta.

- Én is látom azt a rohadt órát, nem kell mondanod! - vágta rá Lajos.

- Milyen kabát ez? - nézett Editkére. - Ilyen kabátot kell ráadni? Hát hogy néz ez ki?

- Igen böszme - helyeselt Lajos.

- Miért nem azt a lila kabátot vetted elő? - fordult lányához Márta. - Az olyan aranyos. Ezt az undorító kabátot kellett ráadni? Ki adta rá?

- Én - felelte rezignáltan Leó. Anyósa folyamatosan kritizálta tetteit. De a legjobban azt kritizálta, ha semmit nem tett.

- És nem láttad hogy néz ki? Nekem kellett volna előkészítenem Editke ruháját. Forduljunk vissza! Ebben a kabátban nem mutatkozhatunk.

Lajos, mit sem törődve unokája beszédfejlődési stádiumával, cifrát káromkodott. Az autó vissza kanyarodott.

- Ott van a nagy szekrényben, majd kihozom - mondta Márta.

- Nem, mert te lassú vagy, majd én - vágott közbe Lajos. Kiugrott az autóból és eltűnt a házban. Kisvártatva az utcafront felőli ablak függönyét elhúzta és felemelte a kabátot, hogy Márta azonosíthassa. Mikor párja bólintott, már el is tűnt és robogott vissza a zsákmánnyal.

- Most nézd meg, Apád hogy hagyta a függönyt! - mondta lányának. - Most miért nem lehetett rendesen visszahúzni? Mint a putri, úgy néz ki. Már nem érünk oda a templomba.

Közben Lajos megjelent a kabáttal.

- Nézd meg a függönyt! Nézd meg! - ordította Márta, amint Lajos kinyitotta a kocsiajtót és beadta a kabátot. - Így kell otthagyni?

A kocsiajtó a kelleténél nagyobbat csattant, majd Lajos dúlva-fúlva visszament a házba.

- Ez egy esőkabát - állapította meg Anna.

- De sokkal aranyosabb, mint ez a másik - mondta erőtlenül Márta. Nem is hozakodott elő a ruhacserével. Közben Lajos is megjelent, szép nyugodtan. Bezárta a kaput, ráérősen a kocsihoz ballagott. - Most nézd meg apádat! Direkt nem siet! El fogunk késni és direkt nem siet!

- Most jó a függöny? - vetette oda foghegyről.

- Úgy nézett ki, mint egy lepratelep!

- Miért nem tudtad normálisan mondani?

- Normálisan mondtam.

- Ordítottál, mint egy szamár. Lehet, hogy a te fejedben normálisan hangzott, de nem az volt. Editke, ezek negatív példák, ne figyelj ránk.

Lassan megérkeztek a templomhoz. Amint kinyílt az ajtó, Editke Leó karjába fúrta magát és ki sem jött onnan, míg észre nem vette a földön futkosó rovarokat. Akkor leugrott és nekilátott gyűjteni.

A mise tovább tartott, ezért a keresztelő még nem kezdődött el. Szerencsére nem késtek el. Anna testvére, annak felesége és lánya már várták őket. Mindenki üdvözölt mindenkit, Editkét kivéve, aki csak a  hangyákkal volt elfoglalva.

Miután a miséről kiáramlottak az emberek, a keresztszülők és a kis lurkók beáramlottak. Négy gyereket kereszteltek aznap. Az első egy roma család volt. Tetőtől talpig feketébe öltözött a négy keresztszülő. A második családban az anya uralt mindent. A méretekről a nadrágig mindent. Az aprócska apa szinte eltörpült a három keresztszülő mellett. Leóék mentek fel harmadikként. Editke egészen jól elvolt a nagyszülőkkel kb. 5 másodpercig, utána apát akarta. Leó elmagyarázta neki, hogy most nem lehet, de Editkének jobb érve akadt: torka szakadtából üvölteni kezdett. A templom visszhangzott 

Leó így felkapta a kislányt és felvitte őt is. A pap megkérdezte, őt is keresztelik-e, de Leó csak megrázta a fejét.

Az utolsó család a teljes szabadság jegyében mellőzött minden ünnepélyes ruhát. A család tagjai melegítő nadrágban jelentek meg, az apa még egy kendőt is feltett. A keresztszülők karját teljesen beborították a tetoválások, amit a rövid ujjú pólóknak hála mindenki láthatott.

- Editke, most csendbe kell maradni - súgta lánya fülébe Leó.

- Nem! Senki sem marad csendben.

- De igen, csak nézd meg! Te vagy az egyetlen, aki hangoskodik.

- Nem akarok csendben maradni!

A szertartás közben elkezdődött. A hangosításnak hála, az oltárnál állók nem hallottak semmit. Leó, hogy elterelje lánya figyelmét, megpróbált érdekes dolgokat mutatni neki.

- Nézd, milyen szép nagy gyertya.

- Nem, nem szép.Semmiképpen nem szép.

De Editke ellent mondott még a papnak is. Mikor az a rész következett, hogy a keresztszülők hisznek-e Jézusban, a kislány ellentmondást nem tűrő hangon kijelentette:

- Nem!

De ugyan így nem hitt a feltámadásban, örök életben, sem semmiben, amit a pap akart a hívek szájába adni. Ellenállása egy rövid ideig szűnt csak meg, mikor a gyerekek a keresztvíz alá kerültek. Korábban ugyanis szülei elmesélték, mire számíthat a szertartás alatt. Egyfajta felkészítésnek szánták. Mikor felismerte, hogy amiről beszéltek neki, most valósággá válik, elkezdte kommentálni az eseményeket.

- Most leöntik a fejüket. Sírnak, mert vizes lett a hajuk. - tényleg sírtak. Nem számított sem kor, sem hovatartozás. Amint a gyerekek fejét víz érte, ugyan úgy üvöltöttek. Akár kvartettet is alkothattak volna.

A pap keresztet rajzolt a gyerekek homlokára, Editkét ez már nem érdekelte. Körül nézett, lát-e valami érdekeset, majd kijelentette, hogy menjen mindenki haza.

- Még nincs vége a szertartásnak, még nem megyünk haza.

- Haza akarok menni. Senki nem marad itt.

- Még nincs vége.

- De vége van. Mindenki haza megy.

- Ezt nem te döntöd el.

- De!

Leó nem szólt semmit, látta, hogy észérvekkel nem lehet hatni lányára. Editke is csendben maradt, mert nem volt kivel vitatkoznia. Közben a szertartás is véget ért. Az emberek lassan elhagyták a templomot. Újra, kint a napfényen Leó azon gondolkodott, mi a fene volt ez az egész felhajtás. Miért volt erre szükség? Abban sem volt biztos, minek volt a részese. Végig csináltak egy színjátékot, mert mindenki végig szokta csinálni. De mennyivel lettek többek?

- Menjünk haza - mondta Editke. Leó lenézett lányára. - Menjünk - mondta. Mit sem törődve az illemmel, a szép ruhákkal, felvette a nyakába lányát, aki érdekes módon nem mondta, hogy "nem tetszik".

Eljött a harmadik nap is. Ismét megkaptam a magamét. Eldicsekedtem, hogy rákkutatással foglalkozom, mire kioktattak, hogy a dohányzás nem is okoz rákot, csak a stressz és az élelmiszer adalék anyagok. Egy ideig gondolkodtam, hogy reagálok valamit, de aztán úgy döntöttem, felesleges. Szépen végighallgattam az érveit.

Érdekes módon találkoztam egy régi motorossal is, aki retro számítógép megszállott és évek óta Luxemburgban él. Átautózott a partyra majd' minden nap, a családi vacsorát kihagyva.Teljesen odáig volt, hogy még vannak mások is, akik ezekre a régi gépekre kódolnak.

A mai nap első megmérettetése a futtatható zenék voltak. A legnagyobb bajom, hogy az alkalmazott kódról nem sok leírást lehetett olvasni, így amikor azt látom, hogy ennek vagy annak a programnak SSE 4.1 kell, akkor nem értem, miért. Többször előkerült a hangszerek fizikai modellezése a leírásban, de ez sem tiszta nekem. Ettől eltekintve elég barátságos volt a felhozatal, de nem nagyon volt olyan, amit a telefonomra töltenék.

A 4k futtatható grafikák tetszettek, nem volt olyan, ami spontán ovációra készteti a közönséget, de a készítők tényleg kitettek magukért, nem lehet ok a panaszra. A régi gépekkel készített képekben az tetszett a legjobban, hogy alig volt konvertált kép. (Amikor a lusta készítő fog egy fényképet, átkonvertálja az adott platform formátumára és hártadől. Persze a konvertálók ezt nem ismerik be és bizonygatják, hogy mennyik kell még dolgozni a kovertálás után, de nem szabad bedőlni nekik.)

A modern grafikai felhozatal szerény volt, a prímet a nagy nevek vitték (Made, Lycan, Unreal, nem feltétlenül ebben a sorrendben). A Poo-Brain azt kell mondani, jön föl. Oni képe simán megállja a helyét a nagyok között.

A Wild a szokásos zenegyűjteményekkel és DOS 256b-al indult, aztán jött valami, amit Atari Music Videónak hivnak. Egy CPU nélküli zenei kütyü. A bemutató videón szétszedték a gépet és meg kell mondanom a Sokol rádió bonyolultabb elektronikával van felszerelve, mint ez a vacak. De ez nem akadályozta a csapatot abban, hogy demót készítsenek rá. Dekadence továbbra is a 20 éves évfordulóját ünnepelte, ezúttal egy 3D nyomtatóval. Ha lenne olyan kategória, hogy a leghülyébb platform, akkor a valódi motorra szerelt mobil telefon által irányított Amigás motorszimulátor biztosan jó eséllyel pályázna rá. Felejtsd el a virtuális valóságot, ha a valósággal irányítod a virtuális világot.

Az animált GIF egy elég furcsa kategória számomra, de most mintha láttam volna az értelmét. Olyan rövid poénokat lehet készíteni, ami önmagában nem elég egy videóhoz, képben pedig nem jön át. Elég marginális kategória, most mégis úgy éreztem, volt értelmük, mégha a legtöbb alkotás felejthető, akkor is.

Az utolsó grafikai megmérettetés a Paintover volt, ahol egy kriksz-krakszra kellett értelmes képet készíteni. Még most is megdöbbent, mit képesek az emberek belelátni egy halom vonalba. Legközelebb egy kínai újság gyászhirdetését kéne nekik adni, mert úgy látszik, ez túl könnyű a résztvevőknek.

Persze beteg játékokból sem volt hiány. Lángszórósként macskákat égethettünk (akik veszélyeztették a zöld területeket), a jó öreg Snake lövöldözős verzióját is láttuk, de még a jó öreg Pongot is megbolondították (az egyik ember a léceked, a másik a labdát irányította).

Nem akartam úgy járni, mint tegnap, ezért elmentem aludni kilenc óra magasságában, pont a koncert alatt. Bár az alvó helyiség a hangfalak mögött volt, olyan erővel dübörgött a föld, hogy azt hittem a frontvonalon vagyok. A csontjaimban éreztem a zenét. Majd meglátjuk, mire lesz elég ez a pihenés.

Az esti kompók közül a 8k volt az első. Mindjárt kaptunk is egy Function invitációt beszéd szintetizátorral. Fulcrum is készített egy beszólós intrót. Kis tankok nyírták egymást nagy erőkkel, míg végül csak egy maradhatott. Egy másik prod is odaszólt az Alcatraznak, igaz csak a leírásban. A kihívásra meg is jött a válasz. Egy igen összeszedett produkciót tettek le az asztalra, több jelenettel, letisztult színekkel és kellemes zenével. Aztán megismétlődött az, amit tegnap a 4k-nál. Elkezdtek jönni a jobbnál jobb produkciók. Homokvihart kavaró kockák, Holdra szálló emberek.

Az oldschool 4k-k nem voltak olyan jók. Huszonöt byte Atari zaj, hosszú C64 scroller, régi PC-s . A Dekadence ismét megünnepelte 20 éves fennállását. Úgy tűnik, 4k elég kevés ezeknek a régi gépeknek.

Az Amigás demókra már nem lehetett panasz. Folytatódott a "minél kevesebb gyorsítás" irányzat. Vagy sima 500-asra vagy közönséges 1200-esre készült a legtöbb produkció. Persze egyesek továbbra is kipaszíroztak mindent a 060-as gyorsítókártyákból. Charlie - az Amigás kompók egyik szervezője - elmesélte, hogy valami speckó kártyának köszönhetően 70MHz-en pörgött a kompógép, aminek örülhettek azok, akiknek nem volt idejük optimalizálni.

Végül eljött az éjszaka fénypontja, a PC-s demók. Annyi volt, hogy a felénél szünetet kellett tartani. Sajnos a 4k-nál látott csoda nem ismétlődött meg, nagyon sok közepes, gyenge produkció volt. Három alkotást emelnék ki a demó tengerből: A Terraforming egy halvány filozófiai hangvételű demó, ennek megfelelő lassú történet meséléssel. A Viianki egy érzelmekre ható, a természet szeretetét előtérbe helyező produkció. Végezetül nem mehetünk el szó nélkül a Spacepigs infantilis alkotása mellett, ahol megismerkedhettünk Kevinnel, a csámpás fogú kisfiúval, akinek hangulat változásait a fogai mozgásából tudhattuk.

Összességében jó kis party volt, a kezdeti nehézségek rendeződtek, sikerült aklimatizálódni és nagyon jó volt látni ennyi remek produkciót.

Délelőtt elég meleg volt, jártam egyet a városban. Ma már compók is voltak. A tracked zene, mint ahogy a zenék lenni szoktak, elég vegyes volt, de Blalával jól kibeszéltük valamennyit.

Az ANSI kompóra Luisa valami állati totemoszlopot készített és volt egy apácás, ahol érdekes átmenet volt a vallás és a pokol között. A többiben nem láttam elég fantáziát.

A régi zenéknél szinte minden platform felvonultatta magát. Hiányoltam a pörgősebb számokat, amiket a tracked zenék között lehetett hallani. Ott is elég sok Amiga volt, tehát nem technológiai akadálya volt a ritmus hiányának. Az egyik legjobb a Cintrustrial volt. A zenét egy program valós időben generálta (némi precalc után, a leírás szerint). A hangzás kicsit nyers volt, mintha egy fémfeldolgozó üzemben vették volna fel. Talán emiatt ütött el a sok csipogástól.

A másik meglepő alkotás a Size Matters volt, ami PC speakeren szólt. Csak egy egészen halk sípolás volt, szerintem valódi vason nem szólna ilyen szépen. Legaábbis, amiket eddig hallottam, inkább idegesítő volt, mint szórakoztató.

A fotók természetesen hozták a jól ismert témákat, de talán csak nekem, úgy tűnt több retusálást engedtek meg, mint máskor. Némelyik kép simán megállta volna a helyét Freestyle grafikaként is.

A videók között ismét volt vicces alkotás, aminek örültem: A Saarbrücken busz, mint veszélyeztetett faj. Volt két családi alkotás is, ahol ilyen-olyan módon a gyerekek is részt vettek a mű elkészültében. Mivel egyre több a családos ember, ez nem meglepő. A Poo-Brain tovább tökéletesítette drón-kamerás technikáját. Nem tudom, milyen géppel voltak felszerelve, de igen impresszívre sikeredett filmük.

A PC 4k intrók első három alkotása a gyorsan felejthető kategóriába sorolható. A negyedik viszont már érdekes volt a maga fizikai szimulációjával, még akkor is, ha már láttunk jobbat Archeetol. A raymarching technikával készült prodok összehasonlíthatatlanul jobbak voltak "hagyományos" társaiknál. Az nwep igazán megdöbbentő volt, aztán jött a Second Stage Boss folytatásának is tekinthető Final Stage. Öt kis űrhajó pusztított el egy Halálfraktált, vagy valami hasonlót. És még mindig nem volt vége! Csak jöttek a durvábbnál durvább intrók. Egy percig nem unatkozott az ember. Ősi űrhajó, változó évszakok, paráztató gömb, minden volt. És ez még csak a 4k volt.

Az Amigás intrók kevesen voltak, de jók voltak. Ha az eddigi kompókból nem derült volna ki,  a Dekadence 20 éve gyárt különböző releaseket. A zenei kompók után most egy Amiga intrót is dedikáltak a nagy eseménynek. A zene elég monoton lett.

Utána rögtön következtek a 64k intrók. Bero szoftveres szintetizátorát demonstrálta egy kicsit hosszú és monoton intróban. A második egy szél energiának szentelt intró volt, furcsán forgó propellerekkel. Ezután lemerültünk a tenger mélyére, ahol egy elsúlyedt várost láttunk. A tenger után egy távoli bolygón guruló kis gömb kalandjait tekinthettük meg a Poo-Brain előadásában. A Dekadence intrója, mintha nem is lett volna. Tovább tartott leírni ezt a pár szót róla, mint maga az intró. Az Approxymate nem tudom, mit csinált, de az jól nézett ki. Értetlenkedésem kiterjedt a következő prodra is, ahol még a készítők nevei sem mondtak semmit (Macau Exports?). A Mercury most csak összedobott valamit a partyra, de ha ők összedobnak valamit, még az is a felső harmadban végez. A Conspiracy alkotásában egy kis kocka utazását követhettük végig, talán kicsit hosszabban, mint kellett volna. Az utolsó produkció a Logicoma beszólós 64k-ja volt, ahol az összes nagy nevű csapatot eliminálták és jelezték, hogy színre léptek.

Az oldschool demókon elaludtam. Néha felébredtem, és láttam, hogy még mindig fut az Overdrive 2. Mondtam is magamban, hogy ez tök jó, majd adás szünet. Bocs.

Nyuszikát és egyéb családi ünnepet hátrahagyva bepattantam Archee kocsijába és elhúztam Németországba az idei Revisionre. Az esemény a tervezési fázisában még jó ötletnek tűnt (kihagyni az értelmetlen zabálásokat, hallgatni, ahogy megvető megjegyzéseket tesznek az ajándékokra, vagy bármi másra, amit az ember tesz). De ahogy itt ülök és nem találom a helyemet, már nem olyan vicces.

Az utazás elég hosszúra sikerült. Mivel Archee-ék péntek reggel korán akartak indulni, én már csütörtökön Pestre utaztam, hogy le ne késsem az indulást. Kislányomnak elmagyaráztam, mi fog történni, amit ő így összegzett:

- El akar menni az apukád. - el az a hülye barom.

Utoljára még ágyban aludtam, mert az elkövetkező három napban csak a föld lesz a társam. Reggel Archee Kolumbiai barátnője finom rántottát készített, majd bepakoltunk és indultunk.

Mivel a lány viszonylag keveset tudott angolul, főleg spanyolul ment a társalgás, amibe én nem tudtam bekapcsolódni. A tíz órás út, sok bóbiskolás mellett hamar elröppent. Rendkívüli esemény nem történt.

Ez az első party, hogy nem hozok semmi release-t. A mini csapat egyik tagja sem készült semmivel.

A magyar kontingens egy helyre települt, de mikor megérkeztünk, már csak három szabad hely volt azon a részen. Egy ideig néztem, ahogy kétségbeesetten igyekeznek a három székből négyet varázsolni, majd úgy döntöttem, maga oldom meg a problémát. Ez nem is volt olyan egyszerű, mert minden csapat foglalta a haveroknak a helyet. Végül a Mercury mellett volt egy magányos hely, oda telepedtem.

A Revisionnek mindig van egy témája, ami köré csoportosul a party. Idén ez egy utóposztikus technokrata világ, ahol a demoscene az egyetlen lázadó erő a mindent és mindenkit uralni akaró gonosz multinacionális cégekkel szemben. Az ötlet egész jó, nekem már az invitációnál bejött.

Megtartották a Meteoriks díj-átadót, ahol az elmúlt év legjobb alkotásait díjazták. A Conspiracy hideglelős 64K-ja három díjat is nyert (közönségdíj, legjobb high-end alkotás, legjobb történet). Ez úton is gratulálunk nekik.

A lineáris regresszió igen hasznos és sokoldalú, de nem minden esetben van normális eloszlású mintánk, sőt nem minden esetben dolgozunk folytonos adatokkal.

Diszkrét adatok esetén a negatív binomiális regressziót használhatjuk. A név kicsit félrevezető, mert a függő változó igazából pozitív értékeket vesz fel.

Használata R-be nagyon hasonló a lineáris regresszióhoz. Nézzünk meg egy példát:

library(MASS)
model <- glm.nb(y ~ x, data = d)

 Vicces módon a lineáris regressziónál bemutatott példát itt is használhatjuk, mert a génekben található mutációk száma csak egész lehet. Most nincs szükség az adatok transzformálására sem.

genes <- read.table("genes.tsv")
genes.log <- log(genes+1)
nb.model <- glm.nb(snps ~ length, data = genes)
lin.model <- lm(snps ~ length, data = genes.log)

A glm.nb() fügvény futtatásánál kapunk néhány figyelmeztető üzenetet, de ezzel most nem törődünk. Valószínű az adat nem teljesen tiszta, vagy túl sok olyan gén van, amiben a mutációk száma nulla.

Tehát van egy lineáris és egy negatív binomiális modellünk. Melyik a jobb? Amelyiknél a reziduálisok négyzetösszege kisebb:

sum(lin.model$residuals**2)
[1] 34722.41
sum(nb.model$residuals**2)
[1] 28060.83

Mint látjuk, a negatív binomiális modell jobban illeszkedik az adatokra.

Mire használhatjuk még a negatív binomiális regressziót? Genomi töréspontok meghatározására. Ebben az esetben a töréspontok várható számát becsülték meg egy regressziós modellel, majd vizsgálták, mikor találnak az elvártnál magasabb értékeket. Hasonló logika húzódik meg a rákot okozó gének keresésében is. A különbség, hogy a várható értéket a szinoním mutációk alapján határozták meg, és nézték, hogy az aminosav cserével járó mutációk száma szignifikánsan eltér-e vagy sem.

Használhatjuk még RNA-seq-ben a változó expressziót mutató gének felderítésére, és így vissza is kanyarodunk az RNA-seq sorozatunkhoz. A kvantifikálás során ugyanis egy egész értékekkel feltöltött mátrixot kapunk. Az egy génre (vagy transzkriptre) jutó szekvenciák száma az összes mintára nézve, negatív binomiális eloszlást fog követni. A regresszió segítségével meghatározhatjuk a szórást, a szórás segítségével pedig eldönthetjük, hogy a változás, amit látunk csupán zaj, vagy valódi expressziós különbség. A helyzet természetesen bonyolultabb, mert a különböző minták szekvenálása során eltérő mennyiségű readet kapunk, de a mögötte álló logikán ez mit sem változtat.

A negatív binomiális regressziónak van egy gyenge pontja, amiről még nem beszéltünk. Ezek pedig a "túl sok nulla". Nem tudom egészen pontosan megfogalmazni, mit jelent a túl sok, de azt tudom, hogy emiatt ez a fajta modell nem használható egysejtes RNS szekvenálások feldolgozásához. Ilyen esetben a "zero-inflated negative binomial regression"-t használják, aminek nem tudom, mi a magyar megfelelője.

Akit részletesebben érdekel a téma, annak ezt a könyvet ajánlom. Nem egyszerű olvasmány, de gyakorlatilag a teljes koncepciót levezeti.

Néha egyszerűen semmi nem megy. Vannak olyan helyzetek, amikor a legjobb kikapcsolni a számítógépet és semmihez nem érni, ami kicsit is bonyolultabb egy arithmometernel. Ha a vállunkra ül a Bitmumus, semmit nem tehetünk, mással kell foglalkozni, hogy elunja magát és odébb álljon. A legrosszabb, ha még nagyobb energia befektetéssel dolgozni kezdünk.

Egy publikáció ábrájához kellett színskálát készítenem. A clusterProfiler remek csomag, sok szép képet lehet vele készíteni. Csupán egy baj van vele: semmilyen jelölést nem ad az ábrához. Nem tudni, hogy az enrichMapen a piros árnyalatok milyen p-értékekhez tartoznak, a körök mérete hány gént jelöl, stb.

A forráskód böngészése után arra gondoltam, elkészítem magam. Bitmumus ekkor mászott a vállamra és csendben figyelni kezdte, mit csinálok.

R-ben a színátmenetekért a colorRampPalette felelős. Segítségével létrehozhatunk tetszőleges színek között átmeneteket. Mivel gyorsan akartam eredményt elérni, ezért szokás szerint egy karakteres változó nevet használtam. Bitmumus a c-t javasolta és alig hallhatóan kuncogni kezdett.

Az R ezután furcsán kezdett viselkedni. Látszólag értelmes kódok hibaüzenetet kezdtek dobálni. Azt még érdemes hozzátenni, hogy Jupyter alatt tevékenykedtem. Miután láttam, hogy nem vagyok képes a színátmenettel düllőre jutni, elkezdtem mással foglalkozni, természetesen ugyan abban a munkafolyamatban. Ott is egyre-másra kaptam a furcsa hibaüzeneteket.

Kb. fél óra elteltével rájöttem, hogy semmi nem működik, amiben a c() függvényt használom. Bitmumus ekkor már a földön fetrengett a röhögéstől. Nekem még mindig nem esett le. Miért nem megy az egyik legalapvetőbb R függvény? Hozzá sem értem...Kivéve, mikor létrehoztam egy c változót. Biiip. Rossz válasz! A colorRampPalette függvényt ad vissza, nem változót. Sikerült felül definiálnom egy beépített függvényt!

Oké, legalább a hiba megvan. Már csak ki kell javítani. Kernel újra indítás? Bitmumus rekeszizmai begörcsöltek, csak kezével jelezte: csináld, te hülye. Az újra indítást követően még mindig nem kaptam vissza az eredeti függvényt.

Végül bezártam az egész rendszert, kinyírtam minden futó folyamatot. Még a böngészőt sem kíméltem. Visszakaptam az eredeti, értintetlen rendszert. Az órára néztem. Egy óra telt el, de még mindig nem volt színátmenetem. Szépen felálltam és kimentem a szabad levegőre. Bitmumus légszomjal küzdve, négykézláb mászva új áldozat után nézett.

Jessica Chang: Transforming gene discovery by radically open data sharing

A humán gének 51%-áról nem tudni, milyen hatással van a fenotípusra. Az újgenerációs szekvenálásoknak és a bioinformatika fejlődésének hála a felfedezések száma ugrasszerűen megnőtt. A következő 15 évben valószínűleg megugrik a feldolgozásra váró adatok mennyisége, de az elemzési, validálási kapacitás nem fog emelkedni, mert a kísérletek áteresztő képessége még mindig alacsony. Az adatok korai megosztása nem jellemző a kutatókra, mert mindenki magas impaktú lapba akar publikálni, ráadásul a páciens adatok nyilvánossá tétele etikai aggályokat is felvet. A megoldás a MyGene2 lenne, ahol a páciens oszthatja meg a saját vizsgálati adatait. Ez a Web2 alapokon nyugvó ötlet azért is előnyös, mert a kutatók a ritka betegségek kapcsán, ha megírták a publikációt, nem térnek vissza a betegekhez. Itt viszont a hasonló betegségben szenvedő páciensek kapcsolatban lehetnének egymással és információt kaphatnának az újabb terápiás lehetőségekről. Kórkép, fenotípus és a VCF feltölthető lesz, amit bárki nézegethet.

Konrad Karczenski: Prediction of splice variants and transcript-level effects improves the identification of gene-disrupting variants

A funkcionális régiókban a variációk száma lecsökken, de a szekvenálási hibák aránya ugyan az marad. Ha a variáció az intron kivágódás helyén keletkezik, az nem jelent feltétlenül a transzkript megszűnését, ha az intron tartalmaz GT vagy AG szakaszt az eredeti hely közelében, akkor a transzkript átíródhat. Ezen hibák felderítésére a Loftee VEP plug-in alkalmas. A Broad Institute Exac adatbázisa pedig összegyűjti ezeket. A potenciális kivágódási helyek megtalálására a MaxEstScan a legjobb program. A programból lesz új verzió is, amibe már integrált gépi tanulásos algoritmusok segítik a felhasználót.

Martin Kircher: Advancing massively parallel reporter assays for interpreting regulatory variants

A ritka variációk alacsony mintaszáma miatt nehéz szignifikáns eredményeket kihozni, ezért a megtalált variációk klinikai hatását a rcare nevű programmal lehet megbecsülni. A nem kódoló szakaszban előforduló variációk is fontosak, ezek felderítésére egy lenti vírus MPRA riporter assey-t kell használni. Ez beépül a genomba, de a beépülés helye nem lehet tetszőleges. A módszerük elég jól reprodukálható, de nem eléggé prediktív az eredmény, ezért a módszer további finomítására szorul.

Jennifer Harrow: Improving the speed of genome interpretation via network collaboration and knowledge sharing

Az Illumina felhő alapú genom elemző megoldása, a BaseSpace, több pipeline-t is tartalmaz. A szolgáltatáshoz tartozó AppStore-ban a felhasználó kiválasztja, milyen eszközökkel akar elemezni, majd fizet és megkapja az eredményeket. Nukleotid variációk keresésére még mindig a BWA+GATK a legjobb, struktúrális variációk felderítésére viszont a Delly-nél jobb a Manta. A megtalált variációk biológiai hatásának értelmezésére is van eszközük, ami állítólag 15 perc alatt lefut egy humán VCF-re. Ugyancsak van páciens fenotípus predikció is. A végső riport készítő alkalmazásuk pedig gyönyörű, publikáció kész összesítéseket bocsát a felhasználó rendelkezésére.

Jared Simpson: Analysis methods for nanopore sequencing data

Nanopore szekvenálás egy membrán két oldalán feszültség különbséget mér. A membránon keresztül vezet egy protein csatorna, amin ha átmegy a DNS, megváltoztatja a feszültséget. 1D-nek nevezik a kapott szekvenciát, ha egy szál halad csak át a csatornán, 2D, ha a reverz komplementer is átmegy. A szignál korrelál az átvándorló DNS mintázatával. Egy eseményből (frekvenia változás) 5 vagy 6 méretű k-mer szekvenciájára lehet következtetni (bár a homopolimer hiba magasabb 6-mernél). A hivatalos base caller a Metrichor, de a közösség létrehozta saját base callerjeit. A Nanocall egy rejtett Markov lánc alapú megoldás, csak úgy, mint a Metrichor, de a DeepNano már recurrent neurális hálózatot használ. A szekvenálás hatékonysága is sokat javult az új flowcelleknek hála. Az R7-nél még 81%, de az R9-nél már 92%, ami az új pólus fehérjének köszönhető. De novo összeszerelésnél hasznos eszköz a Nanopolish, ami egy rejtett Markov lánc alapú konszenzus készítő. Segítségével tovább csökkenthető a hibás nukleotidok száma. A szerkezet képes minden féle bonyolult könyvtárkészítési procedura nélkül metilált nukleotidok azonosítására. A base caller ebben az esetben kiterjesztett nukleotid készletet kap, hatékonysága 87% és a módszer hibája úgy tűnik kontextus függő.

 Kerstin Howe: Curation of multiple genome assemblies of the same species and utilisation for reference improvement

Az előadó a GRC referencia genomok felügyeletétől jött. A referencia ellenőrzésére a gEVAL, Gbench programokat használják, de vannak saját curátor eszközök is. Az információt több helyről kapják. Vannak kapilláris szekvenálási eredmények, alternatív módon összeillesztett referenciák (például CHM1, HuRef embernél, MGSCv3 egérnél). Kérdés, mennyire jók a szekvenciák, mennyire lehet javítani a genomokat? Embernél az elsődleges cél a chr11 javítása, amihez optikai illesztést (optical mapping) és  BAC klónokat, PacBio szekvenálásokat használnak. A kapott konszenzus szekvenciákat összehasonlítják. Meglepő módon még mindig vannak hiányzó és hiányos gének, mert a repetitív részeknél fragmentálódik a szekvencia. A kromoszómára nem illeszkedő részeket igyekeznek bevonni az összeszerelésbe, átrendezik a scaffoldokat, eltávolítják a lyukakat és hibás duplikátumokat. Munkájuknak hála 1300 problémát oldottak meg és 3%-al csökkentették az N-ek számát. Aki részletesebben is érdeklődik munkájuk iránt, nézze meg az oldalukat.

Frank Nothaft: Processing genomics data at scale with ADAM and Toil

A szekvenálás igen olcsóvá vált, de a számítógépek még nem tartanak ott, hogy lépést tartsanak az adat áradattal. A processzor mag szám növekszik, a I/O keresztmetszetét horizontálisan skálázódó eszközökkel igyekeznek növelni. A felhő sem jelent megoldást mindenre, mert a performancia sok esetben rosszabb, mint a HPC-k esetében. Egy lehetséges megoldás az Apache Spark. Ez a memória alapú adatbázis iteratív feladatokra a legjobb, erős Python/R/SQL támogatással. Hogyan lehet ezt genomi adat feldolgozásra használni? Először is más logika alapján kell szervezni a munkát, hogy jobban kihasználhassuk a párhuzamos feldolgozás adta előnyöket. A régi fájlformátumok (BAM/VCF) nem támogatják ezt a fajta feldolgozást, mert szekvenciális módon tárolják az információt, valamint az egymásra épülő feldolgozási lépések bizonyos feltételekkel hajtódnak csak végre (legyen a BAM sorba rendezve). Erre a Toil lehet a megoldás, ami egy munkafolyamat építő eszköz, Python alapokon. ADAM-al együtt használva 30-szor gyorsabb sebességet érhetünk el, miközben az eredmények nem változnak. Természetesen nem minden munkafolyamat ültethető át erre a logikára. Haplotípus azonosítás már nem skálázódik hasonló hatékonysággal.

Andrew Farrel: RUFUS: Reference free variant detection improves accuracy

A Rufus egy de-novo mutáció kereső program, ami illesztés nélkül találja meg az eltéréseket. Bemeneti adatai trió adatok. K-merekre bontja a readeket, hashbe gyűjti őket, majd de-novo assemblyt készít az egyedi szekvenciákból. Mivel csak a szekvenciákat nézi, minden élőlényen működik, nem szükséges paramétereket állítgatni. GATK-hoz nagyon hasonló eredményt ad ember esetén, de például a férfi X kromoszómán pontosabbak a találatok, mert a GATK feltételezi, hogy diploid szekvenciákkal dolgozik. https://github.com/jandrewrfarrell/RUFUS

Alicia Oshlack: SuperTranscript: a linear sequence assembled for the visualization and analysis of transcriptome data

Először a readeket összeszerelik a transzkriptekké, majd génekké klaszterezik őket a Corset nevű programmal. A kérdés, hogyan érdemes vizualizálni az egyes izoformákat? Ők úgynevezett szuper transzkripteket készítenek, ami minden lehetséges szekvenciát tartalmaz. Az így kapott mesterséges szekvencia akár differenciál expressziós vizsgálatokra is használható. Előnye, hogy könnyen áttekinthető az exon lefedettség, nem kell aggódni a több helyre illeszkedő readek miatt. A Lace nevű program képes a beadott klaszterekből szuper-transzkripteket építeni. Nem model organizmusokhoz is használható és akár variációk detektálására is használható. Az előadáson bemutatott egyik ROC görbe, ami az egyes transzkriptek expresszióját hasonlította össze, nem volt teljesen meggyőző, de egy másik példában olyan új csirke szekvenciát találtak, ami nincs benne a genomban. A hagyományos differenciál expresszióval való összehasonlítás eltérést mutat a két módszer között, de az előadó szerint a szuper-transzkript ennek ellenére is jobb módszer.

 Jouni Siren: GCSA2: A scalable approarch to indexing population variation graphs

Hogyan indexeljünk útvonalakat gráfokban? Ez egy kompromisszum az index mérete, részletessége és a keresés hatékonysága között. A gráfok számítógépes reprezentálásá folyamatosan fejlődött. Először deBruijn gráfokat használtak, később ezt felváltotta az FM index. A legújabb adatstruktúra a GCSA2. A gráfoknak lehetnek redundáns algráfjai, amiket ha összevonunk, kisebb memória méretet érhetünk el. Egy LF térképezésnek nevezett eljárás segítségével hosszú, egzakt egyezéseket derítenek fel a gráfokban. Az implementáció az 1000 genom variációit 7 óra alatt 387 GB-ra tömöríti és 4 mikroszekundum alatt megtalálja a keresett szekvenciát. Sebességben a BWA szintjén jár.

Birte Kehr: Unknown and non-repetitive sequence in the Icelanders genomes

Az izlandi emberek szekvenálása során olyan szekvenciákra bukkantak, amelyek nincsenek benne a referencia genomban, nem repetitívek és nem transzpozonok. Tizenötezer ember genomjából a nem illeszkedő readeket kiszedték, kiszűrték a mikrobiális genomokat, a maradékot Velvet segítségével összeszerelték. Csoportokba rendezték a kontigokat és variációkat kerestek bennük. A fenotípus még nem teljesen beazonosított, de struktúrális variációkkal találtak asszociációkat.

Katie Pollard: Decoding enhancer function with machine learning

A távoli enhanszerek beazonosítása, a szabályozott gének megtalálása és az enhanszerek mutációinak hatásvizsgálatára gépi tanulási módszereket vetettek be. Sok esetben a Chip-seq nem az enhanszereket azonosítja, a peakhez legközelebbi gén nem minden esetben a szabályozott gén. A szabályozás ennél komplexebb. Az EnhancerFinder képes elkülöníteni az aktív enhanszereket, egy másik eszköz, a MotifDiverge segítségével pedig megállapítható, hogy a transzkripciós faktorban azonosított mutáció a funkció elvesztésével jár-e. Chip-seq adatok mellett publikus Hi-C adatokat is feldolgoztak és azt vették észre, hogy a peakhez közeli gének sok esetben nem szabályozottak. A TargetFinder segítségével a komplex interakciók is azonosíthatóak. Azt a hipotézist vették alapul, hogy ha mutáció keletkezik a szabályozó régióban, akkor az a DNS alakjának megváltozásával jár, mert a transzkripciós faktorok térbeli alakokat ismernek fel. DNAshape program 5mereket rendel struktúrálist formákhoz. Egy hipergeometrikus teszttel megnézték, hogy ezekhez a strukturális formákhoz lehet-e szekvenciát rendelni. A peakek 25%-hoz sikeresen rendeltek összetartozó térbeli formát és szekvenciát. Az eredményeket CRISPR/Cas rendszeren ellenőrzik.

Chris Probert: DeepNuc: A deep learning model that accurately predicts genome-wide nucleosome positioning from ATAC-seq

ATAC-seq-el a nyitott kromatin régiókat lehet meghatározni. V-plotot használnak az eredmények megtekintéséhez, de a nukleoszóma kötőhelyek megtalálása így is nagy kihívás. Nagy mélységű neurális hálót tanítanak be, ahol az első réteg egy konvolúciós mátrix, majd 6 rejtett réteget használnak és különböző szűrőket használnak a különböző jellemzők azonosítására. A kimenet a MNáz szignál. Az eredmények összehasonlításából az derül ki, hogy bár a random forest módszerek is egészen jó eredményeket adnak, az előadó módszere még annál is jobb, split-ATAC-seq-el egyenesen tökéletes.

Michael Hoffman: Transcription factor expression and its effects on binding site occupancy and motif preference

A transzkripciós faktor kötése sejtvonal függő, ezért RNA-seq-et és Chip-seq-et csináltak ugyan abból a szövetből, hogy meghatározzák a kötés preferenciáját. Azt találták, hogy a peakek erőssége korrelál a gén expresszióval. Azt is észrevették, hogy különböző motivumok más-más szövetekben aktívak. A motivumokat klaszterezése után azt találták, hogy a motivumok sejttípus függőek, de biológiai validálást még nem végeztek.

Anshul Kundaje: Deep learning transcription factor binding sites and regulatory sequence grammars in diverse cell types and lineages

A gépi tanuláson alapuló módszerükhöz a tréning adata az 1kb hosszú genomi régiók, amelyek átfednek a transzkripciós faktor peakekkel. A negatív adatszett azokat a régiókat tartalmazta, ahol nincs átfedés. Ha elég sok konvolúciós réteget halmoznak egymásra, motivum kombinációkat is képes megtalálni a rendszer. Habár különböző bemeneti adatokkal tanították a rendszert (ATAC-seq, MNase-seq), a rendszer nem tűnik elég kiforrottnak. Például a Homerrel történő összehasonlítás során az eredmények inkább az utóbbi felé hajlottak. Valószínűleg a negatív adatszettel lehetett valami probléma. Link, link.

Vera Kaiser: Mutational biases drive elevated rates of substitution at regulatory sites across cancer types

A nem kódoló variációkat nem kutatják olyan intenzíven. A transzkripciós adatbázisok átnézése közben azt vették észre, hogy kicsi az átfedés közöttük. Khi-négyzet probával összehasonlították a rákhoz köthető gének szabályozó régióit egy kontrol régióval, nézték a mutációs spektrumot és vizsgálták a variációkat. Azt vették észre, hogy a CTCF kötőhelyeknél a mutációk aránya eltolódott.  Regressziós analízissel igyekeztek meghatározni, mely hatások a legjelentősebbek (pl. replikációs idő), de csak azt találták, hogy mindegyk fontos.

Kim Pruitt: NCBI graphical display tools – Hidden in plain sight

Az NCBI-nál egy új genom nézegetőt készítettek. Érdekessége a többi, hasonló kezdeményezéssel szemben, hogy ez tetszőleges weboldalba integrálható, majd saját annotációt lehet hozzárendelni. A terv az, hogy a GEO-ból is elérhető legyen. Bemutatták a Genome Workbench legújabb verzióját is, a tervek szerint ez fogja leváltani a SeqIn-t.

David Powell: RNA-seq visualization using Degust

A Degust, ahogy az előadás címe is mondja, egy kollaboráció központú RNA-seq vizualizációs program. Mivel az RNA-seq analízsre számtalan megoldás létezik, ezért ezeket építették be a Degustba és inkább a kutatók együttműködésére helyezték a hangsúlyt. Számtalan interaktív eszköz áll a kutatók rendelkezésére, hogy a differenciál expressziós eredményeket nézegessék. A bemenet egy nyers mátrix, amit webszerver alapú alkalmazás ezután feldolgoz. Magas szinten működik, de a hozzáértőknek lehetőségük van, hogy akár az ábrákat generáló R kódot is megtekintsék. A rendszert lehet az eredmények tárolására is használni. Érdekessége, hogy eredetileg Haskelben írták, de végül NodeJS-ben implementálták újra: https://degust.org

Jonathan Manning: ShinyNGS: Interactive data mining with R and Shiny

A Shiny egy webes keretrendszer R-hez, interaktív weboldalak készítéséhez. Ezen alapul a ShinyNGS, ami az analízis végén helyezkedik el és a már analizált eredmények megjelenítésével foglalkozik. Az előadásban példákat láttunk a használatára. A szerzők szeretnék kiterjeszteni egy sejtes RNA-seq-re is. https://github.com/pinin4fjords/shinyngs

Davis McCarthy: Using single-cell RNA-seq data for inference on gene regulation

Az egy sejtes RNA-seq népszerű, mert egyszerű dimenzió redukciós módszerekkel a sejt differenciálódás nyomon követhető. Az expresszió a differenciált sejteknél alacsonyabb a pszeudó idő skálán. A jó eredményekhez természetesen jó bemeneti adatok is kellenek. A scater csomag segítségével a QC könnyen megállapítható. A normalizálásra még nincs általánosan elfogadott módszer, de az scran elfogadható eredményt ad. A különböző batch effektek eltávolítására még mindig az ismétlésszám növelése a legjobb módszer. A hagyományos RNA-seq módszerek nem alkalmazhatóak.

Hagen Tilgner: Comprehensive transcriptome analysis using synthetic long read sequencing reveals molecular co-association and conservation of distant splicing events

A transzkriptek száma magas, hosszúságuk eltérő, de legtöbbször 400-700 bázispár hosszúak. lncRNS-eknek több izoformájuk van protein kódoló társaikénál, míg utóbbiak hosszabbak. Hosszú PacBio readekkel akarták azonosítani az egyes izoformákat. Sikerült új izoformákat azonosítaniuk, allélspecifikus variációkat is találtak, sőt egyes esetekben még új exononokat is felfedeztek. A kivágódások száma a polyA véghez közelebb megnő. Azt is észrevették, hogy összefüggés van a promóterek és az alternatív splicing között.

Simon Hardwick: Spliced synthetic genes as internal controls in RNA sequencing experiments

Az RNA-seq szekvenálások minőségéről az úgynevezett spike-in kontrol használata ad felvilágosítást. Ezeket a mintáktól jól el kell tudni különíteni. A szintetikus szekvenciák 78 gént tartalmaznak, 164 izoformát, egytől 36 exonig. A méret eloszlásuk 250 nukleotidtól 7kb-ig terjed. A hozzáadott kontrolok koncentrációja fontos, mert ha túl alacsony, akkor az FPKM és a tényleges koncentráció között nagyon nagy lesz a szórás. (Az előadó szerint 5.17 FPKM alatt a model nem használható.) www.sequin.xyz

Pali Meisted: Fast fusion detection, assembly, and quantification using kallisto

A fúziós géne fontos szerepet töltenek be a rák diagnosztikában. Az alap Kallisto k-merek segítségével azonosítja a transzkripteket és ha inkonzisztenciát talál a referenciával, eldobja azt. Ezért az alap program nem jó fúziós gének keresésére. A módosított program ellenben visszaadja azokat az eredményeket, amelyek nem fednek át ismert transzkriptekkel. A fals pozitívok száma magas, de a futási idő csupán 5 perccel növekedett meg. A fals pozitívok egy része a rossz annotációból ered.

A Sangerben általában hatékonyan mennek a dolgok. Természetesen itt sokan panaszkodnak, hogy a rendelési rendszer bonyolult, az állatházban fintorognak, ha egyedi kérés van, stb, de összességében szerintem tervszerűen haladnak.

De nem hiba nélkül. Ha pedig hibáznak, akkor az nagyot szól. Összességében kétféle hibát lehet megkülönböztetni. Az első kategória a "hagyományos" hiba, amikor valamit elterveznek, de nem úgy sikerül végrehajtani. A második kategória, amikor eltervezik, végrehajtják, de onnan nincs továbblépés, mert azt már nem tervezték el.

Az első bemutatandó példa Katerina esete. Közel 760 PDX mintát kellett volna feldolgoznia. A PDX (patient-derived xenograft) alapja, hogy a humán rákos sejteket egérbe oltják és ott növesztik. A szekvenálás során tehát a minta meghatározatlan mennyiségben egér DNS-t is tartalmazott. Ezt így tervezték, csak épp a bioinformatikusoknak nem szóltak előtte.

Mivel a pipeline-t nem hibridek feldolgozására tervezték, az IT nem nyújtott segítséget. Katerina talált egy R szkriptet, ami megoldja a problémát, de mivel csak neki volt rá szüksége, az IT nem telepítette azt a központi gépekre. Pont helpdeskes voltam, amikor felkeresett, hogy segítsek neki telepíteni a modult.

Biztos fantasztikus ötlet húzódik a program hátterében, de a megvalósítás hagy némi kívánni valót maga után. Először is, a program saját maga akarta elkészíteni a BAM indexeket és ezért a szimbolikus linkeket is visszakövette eredeti helyükre. Ami az iRODS szerveren van, halandók számára csak olvasási joggal.

Mikor erre rájöttem, módosítottam a modul kódját és onnantól már használható is volt.

A másik eset az én csoportomban történt. Közel 1400 mintát szekvenáltak meg és a DNS izolálás több tálcán történt. Kutatónk, hogy gyorsítsa a munkát, nem feliratozta a csöveket, hanem a tálca-pozíció alapján azonosította a mintákat. Az egyik lépésnél, amikor pipettázni kellett egyik csőből a másikba, a monoton munka hatására kimaradt egy cső, amit csak az egész folyamat végén vett észre.

Megvolt a három technikai ismétlés, de csak a Nedves Labor Nagy Szelleme tudta, hogy melyek azok. Az egyetlen dolog, amit tehettem, hogy mind az 1400 mintát hierarchikusan klasztereztem, hogy megtudjam, mik tartoznak össze. Ez nem volt olyan egyszerű, mert igencsak az elérhető memória (1,5 Tb) felső határán járt a szkript és ott futott több, mint négy napig. Kétszer is le kellett futtatnom, mert a fát tartalmazó PDF nem volt elég széles, hogy olvashatóak legyenek a feliratok.

Egyébként a legszaftosabb szekvenálási eredmények a Kísérletes Szekvenálási csoport produkálja. Ami tőlük jön, az olyan, mintha az állatorvosi lovat megfőznék a boszorkány konyhában. Csakhogy néhány példát említsek: 1 nukleotid hosszú adaptor, több száz sejtmagot tartalmazó sejtek (egysejtes) szekvenálása. Ezek egyike sem futhat a pipeline-ban. Gyakran a jól bevált programokat sem tudjuk használni. BWA például úgy nyelte el azokat a rövid adaptorokat, hogy öröm volt nézni. Aztán csak néznek nagy boci szemekkel: nem lehetne valamit mégis csinálni? Természetesen lehet, csak had indítsak el egy vim-et.

Ha az ember önéletrajzot készít, hajlamos gyakran összeegyeztethetetlen dolgokat is beleírni:

- Tud Ön egyedül dolgozni?
- Igen, nincs szükségem senkire.
- Ön csapatjátékos?
- Természetesen, akkor érzem igazán elememben magam, ha sok ember vesz körül és közös erővel dolgozunk.

De legutóbb arra jöttem rá, hogy nem vagyok csapatjátékos.

Mit csinál egy csapatjátékos? Egy jó csapatjátékos. Természetesen elfogadja, hogy ő egy kis fogaskerék, megkapja a maga kis inputját, hozzáteszi, amit tud, majd továbbadja a következő fogaskeréknek. Mindenki egy valamivel foglalkozik, nem akar senki több lenni a másiknál, egyformán mosolygunk és kis hangya szívünket melegség tölti el, ha arra gondolunk, hogy a nagy gépezet olajozottan működik.

Ez mind rendben is van. Semmi bajom vele. De vannak pillanatok, amikor a kis fogaskerék arra lesz figyelmes, hogy nincs input. Nincs min csámcsogni és nem lehet mit tovább adni. Természetesen a jó csapatjátékos ilyenkor hátradől és várja, hogy megjavuljanak a dolgok, esetleg egy kicsit zsörtölődik félhangosan, csak hogy lássák, saját hibáján kívül kénytelen Facebookozni.

Ez az, ami nekem nem megy.

Itt a Sangerben a DNS hosszú utat tesz meg az élőlényből a képernyőig. A kutató izolálja a DNS-t, átadja a Központnak, ahol elkészítik a könyvtárakat, betöltik a szekvenáló masinákba. A FASTQ fájlokat illesztik, az illesztést feltöltik egy fájlszerverre. A Rák genom program (illetve idéntől Rák, öregedés és szomatikus mutációk program) ügyintézői levelet kapnak, hogy új szekvenciák érhetők el. Létrehozzák az adatbázis bejegyzéseket (projektet, mintákat) egy weboldalon keresztül, majd a szkriptek működésbe lépnek és megindul az előfeldolgozás. Az előfeldolgozás során megnézik, hogy a szekvenálás milyen minőségű és az eredménytől függően az ügyintézők elfogadják vagy eldobják azokat.

A kutató végül kap egy levelet, hogy kész a projektje, majd a weboldalon keresztül kijelöli, hogy milyen vizsgálatokat kíván végrehajtani és a farm processzorai felizzanak. Ha bármilyen probléma adódna, a program bioinformatikusai (helpdesk) megoldják. Aztán már nincs is más hátra, mint táblázatokat generálni.

Az ügyintézők hárman vannak. Véletlen szerűen rendelik őket egy-egy szekvenáláshoz, de ha hozzárendelték őket, akkor az adott folyamattal kapcsolatos összes levelezést ők kapják. Mivel én tagja vagyok a genom program bioinformatikai csapatának is, nyomon tudom követni a szekvenciák útját, de nincs jogosultságom minden tevékenységhez.

Mi történik, ha például az egyik ügyintéző (vagy kettő) nyáron elmegy két hét szabadságra? Az egész rendszer megreked. Hiába van ott a harmadik, nem kap semmilyen értesítést a már futó projektekről. Az új igényeket megpróbálja kiszolgálni és ezzel el is megy minden ideje.

Én láttam, hogy kész minden szekvenálás, de hiába vártam, hogy elkészítsék a projektet. Végül felmentem az ügyintézőkhöz, de meglepetésemre az egész iroda sötét volt. Visszamentem a gépemhez és létrehoztam a projekteket. Ez nem volt nehéz, még dokumentáció is volt hozzájuk. Eltelt még egy nap és meg kellett volna nézni a minőségi mutatókat. Ehhez már nem volt jogosultságom.

Gondoltam egyet, elmentem az egyik principális bioinformatikushoz és megkérdeztem, kaphatok-e jogosultságot. Azt mondta, ha csak a saját projektjeimet birizgálom, kaphatok. Becs'szóra megígértem. Mire az ügyintéző visszajött, már kész volt minden. (Aztán egy másik alkalommal leszúrtak, mert létrehoztam egy projektet, de a pipeline nem tudta használni azt. Ugyanis nem tudtam, hogy bizonyos referencia szekvencia, analízis kombinációkat nem állíthatok be. Szépen elmagyarázták nekem, hogy a projekt létrehozás nem az én dolgom.)

A másik példa deviáns viselkedésemre és a szabályok figyelmen kívül hagyására Katerina esete. Majd részletesebben is írok róla, most csak annyit elöljáróban, hogy volt kb. 700 szekvenciája, ami vegyesen tartalmazott egér és ember readeket. A pipeline-t úgy tervezték, hogy csak egy referenciával dolgozzon, tehát szerencsétlennek mindent kézzel kellett volna csinálni. Talált valami béna szkriptet, ami a leírás alapján képes megoldani a problémáját, de képtelen volt működésre bírni. A bioinformatikus csoport (a nevünkben benne van, hogy támogató, de ez alkalommal nem támogatták) kétszer hajtotta el, mindenféle segítségnyújtás nélkül. Először azért, mert a rendszer nem kezel hibrideket, másodszor, mert a csoport által nem támogatott szoftvert akart használni. Pont helpdeskes voltam, amikor sokadszorra keresett valakit, aki megoldja a problémáit.

Nekem is egyszerű lett volna a szabályokra hivatkozva lepattintani (a feladatkörben benne van, hogy ha egy munka várhatóan 2 óránál hosszabb időt vesz igénybe, nem kell megcsinálni, hanem akkor a főnökség kirendel valakit a megoldására, ha prioritást élvez), mégsem tettem. A kollégák a szabályokra hivatkozva később is mondták, hogy ne segítsek neki, de mivel nekem nem főnökeim, nem kell hallgatnom rájuk.

Ha ezt jelenti csapatjátékosnak lenni, akkor köszönöm, nem kérek belőle.

A lineáris regresszió az egyik legegyszerűbb gépi tanulás módszer. Tudat alatt mi is sokszor használjuk, ezért a mögötte álló logika könnyen elsajátítható. Az alapkoncepció ugyanis az, ha egy mennyiséget növelünk, egy másik érték is növekedni fog. Egy hétköznapi példával élve, ha a kutyánknak több kaját adunk vacsorára, a súlya is növekedni fog. Itt az étel mennyisége és a kutya súlya áll kapcsolatban.

Ha tovább gondoljuk a példát, akkor érezzük, azért csupán a vacsora mennyisége, habár befolyásolja a testtömeget, nem elég, hogy pontosan meghatározzuk kutyánk tömegét. Tegyük fel, hogy rossz gazdik vagyunk és megengedjük állatunknak, hogy a szemétben is kotorásszon a séták idején. Kedvencünk súlyát tehát a szemétből kihalászott finomságok és a vacsora együttesen jobban meghatározzák, mint a vacsora egymaga.

Modellünknek immár két függő változója van (szemét + vacsi) és egy független változója (testsúly). Természetesen összetettebb modellel is próbálkozhatunk (megivott víz mennyisége, szőr között megbúvó kullancsok száma, stb.), de intuitíve érezzük, a súly meghatározása nem lesz sokkal pontosabb.

Ha eldicsekszünk másoknak is modellünkkel és ők is kipróbálják saját kutyájukon, csalódni fognak. Hamar ki fog derülni, hogy bár nekünk jól működik, más kutyák testsúlyát valami miatt rosszul határozza meg. A modellünk ugyanis nem elég általános, a szomszéd kutyája jónevelt, csak suttyomban eszik a kukák mellől, egy másik ismerősünk rendszeresen fut a kutyával, aki emiatt nehezebben hízik, stb. Jó lenne, ha ezeket a nehezen mérhető különbségeket is megjósolná a modellünk. Ha ezeket az adatokat is bevonjuk a modell generálás folyamatába, mi fog ezután történni? Valamelyik kutya súlyát pontosabban megjósolja, másokét kevésbé pontosan.

Úgy is mondhatnánk, egy idealizált kutya paramétereit kapjuk meg. Egyes kutyák jobban hasonlítanak majd erre a nem létező kutyára, mások (köztük természetesen a sajátunk is), kevésbé. Azt, hogy mennyire hasonlítanak az egyes kutyák erre az elméleti állatra, a modell által megjósolt testsúly és a ténylegesen mért érték különbségéből lehet kiszámolni (egészen pontosan a különbségek négyzetösszegéből).

Lássuk mindezt a gyakorlatban, bioinformatikához is köthető adatokkal. Töltsük le a Drosophila variációkat és genom annotációt. Készítsünk egy táblázatot, ami a gének nevét, hosszát és a bennük található SNP-k számát tartalmazza. Erre a következő szkriptet használhatjuk:

#!/usr/bin/python

import sys
import gzip
import re

class Gene:
    def __init__(self, start, stop, name):
        self.start = start
        self.stop  = stop
        self.name  = name
        self.count = 0

def findGene(genes, pos, starti, stopi, vnum):
    if genes[starti].start < pos and genes[starti].stop > pos:
        genes[starti].count += vnum
    if genes[stopi].start < pos and genes[stopi].stop > pos:
        genes[stopi].count += vnum
    if stopi - starti < 2:
        return
    midi = starti + (stopi - starti) / 2
    if pos > genes[starti].start and pos < genes[midi].stop:
        return findGene(genes, pos, starti, midi, vnum)
    if pos > genes[midi].start and pos < genes[stopi].stop:
        return findGene(genes, pos, midi, stopi, vnum)
    return

geneidpatt = re.compile('Name=([^;]+);')

genes = dict()

gff = gzip.open(sys.argv[1])
for line in gff:
    if line.startswith('#'):
        continue
    fields = line.rstrip().split()
    chrx   = fields[0]
    ftype  = fields[2]
    start  = int(fields[3])
    stop   = int(fields[4])
    match  = geneidpatt.search(fields[8])
    if ftype != 'gene' or not match:
        continue
    genename = match.group(1)
    if chrx not in genes:
        genes[chrx] = list()
    actual = Gene(start, stop, genename)
    genes[chrx].append(actual)
gff.close()

for c in genes:
    genes[c] = sorted(genes[c], key = lambda x:x.start)

vcf = gzip.open(sys.argv[2])
for line in vcf:
    fields = line.rstrip().split()
    if line.startswith('#'):
        continue
    chrx = fields[0]
    pos  = int(fields[1])
    vnum = len(fields[4].split(','))
    findGene(genes[chrx], pos, 0, len(genes[chrx]) - 1, vnum)
vcf.close()

print "length\tsnps"
for chrx in genes:
    for entry in genes[chrx]:
        print "%s\t%d\t%d" % (entry.name, entry.stop - entry.start, entry.count)

Töltsük be R-be a táblázatot és nézzük meg a változóink eloszlását:

data <- read.table("genes.tsv")
hist(data$length)
hist(data$snps)

Ez bizony baj. Kicsit sem hasonlítanak a normál eloszlásra, márpedig ez feltétele a lineáris regresszió használatának. Szerencsére egy egyszerű transzformáció segítségével közel normál eloszlásúvá alakíthatjuk őket. Ezután viszont tartsuk észben, hogy az összefüggésünk nem a gén hossza és a variációk száma között fog fennállni, hanem a transzformált értékek között!

data$length <- log(data$length + 1)
data$snps <- log(data$snps + 1)

R-ben a modell alkotás egyszerű folyamat. Meg kell adni a független változót (snps), jön egy furcsa karakter '~', majd felsoroljuk a függő változókat (jelen esetben ez csak a length). Az összes többi feladatot az R megoldja helyettünk. Érdemes alaposan összeismerkedni a modellekkel (az R dokumentáció formula néven emlegeti), mert teljesen új dimenziókat nyit meg előttünk.

model <- lm(snps ~ length, data = data)

Mit tudunk kezdeni ezzel a modellel? Jósolhatunk. Mennyi SNP-t várunk egy 23926 hosszú génben? Csak jusson eszünkbe, hogy a modellünk logaritmikus skálán működik!

a <- log(23926)
b <- predict(model, data.frame(length = a))

A válasz 7.100061. Ami 1212 mutációt jelent. Ha most megnézzük a 23926 hosszú géneket, akkor azt látjuk, hogy az stnB gén 1407 SNP-t tartalmaz, míg az stnA egyetlen egyet sem. Itt el is kezdhetünk gondolkodni, hogy mindez mit is jelent, de az túlmutat jelen poszt témáján.

Aki további részleteket akar megtudni a lineáris modellekről, annak ajánlom ezt a könyvet. Annyira szájbarágós, hogy még én is megértettem matematikai előképzettség nélkül. A Courseran is több kurzus értinti a témát. (ez, ez és még ez is, csak azokat említve, amiket láttam is.)

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 (IRAP,  Trinity).

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.

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.

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.

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.

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.

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.

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?