Az élet kódjai

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Remélem, azért Nektek tetszik:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

conda create -n env
source activate env

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

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

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

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

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

Bowtie

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

TopHat

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

GSNAP

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

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

STAR

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

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

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

HISat

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Paul miért nem menekül el?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://rnaseq.uoregon.edu/

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

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

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

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

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

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

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

Zene

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

Grafikák

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

Wild/Animáció

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

256b intró

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

Intrók

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

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

Demók

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SNP-k, indelek

Crisp

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

LoFreq

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

deepSNV

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

Caveman

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

Pindel

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

Mutect

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

Struktúrális variációk

Delly2

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

Brass

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

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

Zene

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

Grafikák

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

Játékok

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

Videók

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

Oldschool demók

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

Intrók

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

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

Demók

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

Összegzés

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

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

Vannak eszközök, amiket nem arra terveztek, hogy kikapcsolják. Ilyen a hűtőszekrény, a nukleáris meghajtású tengeralattjáró vagy egy 20 ezer processzoros szuperszámítógép.

Ezen a hétvégén mégis pont ezt tették. Az egész hóbelevancot lekapcsolták a Sanger teljes infrastruktúrájával egyetemben. Egy számítógép kikapcsolása a virtuális memória megjelenése óta bonyolultabb lett a kávéfőző lekapcsolásánál, egy computer farm lekapcsolása pedig még ennél is bonyolultabb.

Miért is? A nagy gép sokkal több áramot vesz fel. Annyit, hogy a vezetékek eltávolítása egymástól (ami minden kapcsoló alapja) ívet képezne, vagyis a levegő is vezetővé válna és szépen világítana egy Hold nélküli estén. Vészleállításhoz van egy ilyen kapcsoló és állítólag egy tábla is, amin az áll: Soha ne használd!

Nem is ezzel kapcsolják le a rendszert. A lekapcsolás előkészítése fél évvel ezelőtt kezdődött. Az intézeti infrastruktúra elég bonyolult, számtalan adatbázis, nyilvántartási rendszer fut, de manapság már a PCR vagy a mikroszkóp is netre van kötve, a rendszerek különböző alá- és felérendeltségben vannak.

És végezetül ott van az egész tetején a legkényesebb, leglogikátlanabb, legkevésbé dokumentált, legkezelhetetlenebb, legidegesítőbb eleme az egésznek: a felhasználó.

Mikor februárban az IT bejelentette, hogy leállás lesz, ahol MINDENT lekapcsolnak, állítólag megkérdezték, fog-e menni a levelezés? Nem - jött a válasz. Fog-e menni a szekvenálás? Nem. Lehet távolról dolgozni? Nem. Ekkor érezhetően pánik kezdett eluralkodni, ami semmivé foszlott, amint kiderült, hogy mindez augusztusban lesz.

Egy hónap múlva mindezt megismételték. Már nem volt pánik, de állítólag szóról szóra ugyan azokat a kérdéseket tették fel. Aztuán hónap elején a managerek végigjárták a csoportokat és akivel csak találkoztak, elmesélték nekik, mire számítsanak.

Elkezdtek megszaporodni a levelek, ahol arra figyelmeztettek, hogy bizony itt mindent lekapcsolnak, ne sok jóra számítsanak. Először csak a havi összefoglaló levelek egy fejezete szólt csak a nagy áramtalanításról, azután jöttek az IT levelei. Egy héttel a nagy esemény előtt már napi szinten kaptuk az információt. Egyes háttér intézmények külön levelet is küldtek, amiben arra figyelmeztettek, hogy a nagy lekapcsolás alkalmával ők sem tudnak egyetlen kérést sem teljesíteni.

A bioinformatikusok is kidolgozták saját ütemtervüket. Először a szekvenálást figyelő szolgáltatásokat kapcsolták ki. Utána letiltották az új analízis kérését, de a futó elemzéseket még hagyták. A farmon is leállították azokat a feldolgozási sorokat, amelyek hosszú ideig is futni engedték a programokat. Bejelentkezéskor figyelmeztető üzenet fogadott minden felhaszálót, mire számítsanak a jövő héten. Végül kézzel nyírták ki azokat a folyamatokat, amelyek úgysem fognak befejeződni.

Ekkor kiderült, hogy egy csoport masszív PCR kísérletet tervez. Nem foglalkoztak semmivel, mert ők úgysem használnak számítógépet. Csakhogy a plate leolvasó A laborban volt, a PCR B laborban, a kettő között meg egy UTP kábel néhány routerrel, switchel, amik szintén nem fognak működni.

Öt nappal a leállás előtt még volt olyan kutató, aki meglepődve vette tudomásul, hogy "valami leállításról beszélnek. Ez érint engem?" Biztos nem volt egyedül a problémával, mert másnap egy két méteres táblát raktak a tudományos élet központjába, a kávézóba, rajta a legtöbbet ismételt kérdésekkel.

Végül leállították az összes szolgáltatást és eljött a hétvége.

De az igazán nagy kihívás nem ez volt. Hiszen van vészleállító, ha nagyon akarják, pár perc alatt lekapcsolhatnak mindent. Mint említettem, ezeket a gépeket nem azért készítették, hogy lekapcsolják. Az igazi ok az, hogy baromi nehéz úgy visszakapcsolni mindent, hogy úgy működjön, mint kikapcsolás előtt. Ezért nem volt még ilyen akció a kampusz történelme során. Ezt mindenki tudja és nincs senki, aki arra számítana, hogy ez zökkenőmentes lesz.

Az IT már reggel hatra bement dolgozni. Áram alá helyezték a gépeket és reménykedtek benne, hogy nem lesz sok hardver hiba. A számítógépek ugyanis jó ideig egy bizonyos hőfokon működtek, de most lehültek. Előfordulhat, hogy nem fognak újra elindulni. De felkészültek tartalék hardverrel.

Azután ott vannak a szoftverek. Mindenki találkozott már olyan helyzettel, hogy egy program egy újra indítás után nem működött. (Ekkor persze újra indítunk valamit, de egy Sanger méretű infrastruktúránál nem mondhatjuk azt: Bocsi, valamit elírtam a konfig fájlban. Nem indítanátok újra mindent a kedvemért? Na, ne legyetek már ilyen izék!) De talán négy óra elég lesz, hogy minden zűrt elhárítsanak.

Reggel 9-re a net helyreállt, 10-kor már egyes weboldalak is működtek, 11-re már e-mailezni is lehetett. A farmra 14.00-kor tudtam először belépni. Mint kiderült a virtualizációs környezet indító szkriptje 10 másodpercet vár a számítógépek indítása között. Ezért tartott 6 órán át az indítás. Ezt leszámítva nem hallottam egyetlen komoly fennakadásról sem.

Ettől függetlenül elgondolkodtatott, mennyire a nettől függünk. Nem csak mi, bioinformatikusok, és nem is csak a tudományos élet szereplői, hanem a mindannyian. Pár hónapja volt egy nagy vita arról, szükség van-e a kézírásra, vagy nincs. A régi iskola képviselői bőszen hangoztatták, hogy milyen hasznos a kézírás, mert ha valami miatt nem működnek a számítógépek, akkor kénytelenek vagyunk visszatérni a kézíráshoz.

A leállás alkalmával mindenki tudott írni, mégsem tudtunk csinálni semmit. Ezzel nem azt akarom mondani, hogy nincs szükség a kézírásra, csupán azt, hogy jelenleg a számítógépek nem helyettesíthetőek papírral és tollal.

Következő bejegyzés olvasása közben javaslom ennek a hallgatását. Végtelenítve, ha lehet.

Szerencsés vagyok olyan szempontból, hogy mindig épp időben kapcsolódok bele egy-egy munkába. Ez volt a mangalica cikknél is és ez történt itt, a Sangerben is. A munka nehezét, vagyis az egerek felnevelését, a sejtek mikroszkópos nyomon követést már megcsinálták, mielőtt megérkeztem volna. Az expressziós vizsgálatok egy része is megvolt, így nekem elég könnyű dolgom volt.

Olyan szempontból is könnyebb volt a dolgom, hogy nem kellett több százszor megcsinálni ugyan azt az ábrát, mert a PhD hallgatók különböző grafikai programokkal addig szerkesztik a képeket, ameddig a csoportvezető azt nem mondja, rendben. Természetesen, ha programozással egyszerűbb átalakítani a képet, akkor azt továbbra is nekem kell, de 10-20 probálkozás után valahogy mindig konszenzusra jutottunk, nem volt túl sok felesleges iteráció.

Eddig nem sokat írtam a főnökömről, de most ideje megtenni. Érdekes keveréke egy bohém művésznek és egy offenzívát vezénylő tábornoknak. Egyfelől, ha beszélgetünk, sokszor terelődik a beszélgetés a ködös jövőre, ahol oxigénmentes környezetben akar szöveteket vizsgálni vagy gamma sugarakkal bombázna állatokat (ez utóbbi terve egyébként kiverte a biztosítékot a managereknél, mert a cézium izotópot tartalmazó berendezésnek 24 órás fegyveres őrzést kell biztosítani.) De ha a kísérletekről van szó, valahogy minden egy irányba mutat. Már a kísérlet tervezése során arra gondol, vajon a reviewer mibe akar belekötni. És mindig szem előtt tartja az időt. Most is volt egy olyan gond, hogy az exome elemzések nem voltak elégségesek az egyik hipotézis alátámasztására, ezért azt javasoltam, csináljunk teljes genom szekvenálást is. Julia aggódott, hogy akkor soha nem fog elkészülni a cikk, mert mire kész lesz a szekvenálás, elemzés, utána küldjük csak be a kéziratot, stb. A főnök erre csak annyit mondott, a teljes genomot biztosan kérni fogják, mert ha ő lenne a reviewer, akkor ő is kérné. De attól még a kéziratot beküldjük, közben elindítjuk a szekvenálást, mire átnézik a cikket, az is lesz egy pár hónap. Az alatt meglesznek az eredmények. Csak álltam és néztem.

Végül az editor azt mondta, hagyjuk ki az exome eredményeket, de Phil már tervezte a következő cikket, amiben viszont benne lesznek. Semmi nem vész kárba. Máshol is jó lenne ilyen hozzáállást látni.

A kirtikához való hozzáállása is más az itteni kutatóknak. Korábban, ha valami baj volt a kézirattal, akkor egyes szerzők sok esetben (tisztelet a kivételnek, mert ilyen is volt) lehülyézték a reviewert: Minek akarja ezt? Nem tud olvasni? Ott van két bekezdéssel előbb leírva. Mit arcoskodik itt?

Itt ennek nyoma sem volt. Úgy tekintettek a kritikára, mint egy véleményre, amitől jobb lesz a cikk. Én egyébként úgy éreztem, az egyik reviewer nem kedvelhette a főnökömet, mert az esszé-szerűen megfogalmazott véleményében oda-oda szólogatott, de mielőtt felkaphatta volna az ember a vizet, mindig tompította valamivel az élét. Példának okáért kifogásolta, hogy megint az asszimmetrikus sejtosztódás két állapota a témája a cikknek, amit már egyszer megjelentettek ebben az újságban. Ha pedig egyszer már megjelent, akkor utána a csoportvezetők az összes ebből származó cikket ugyan abban az újságban jelentetik meg. Ez pedig milyen veszélyes a minőségre, bla bla bla. Majd a következő mondata: de ez nem a szerzők hibája, hogy ilyen a rendszer.

El is mondtam aggodalmaimat, de Phil csak mosolygott egyet és azt mondta: nem kell vele foglalkozni, nekünk az editort kell boldoggá tenni, nem a reviewert. Idézetnek is beillő félmondat. De meg kell jegyezni, a többiek azért rendesen megszenvedtek a cikkel. Emlékszem, hányszor láttam Juliát a gép előtt ebédelni, mert időre le akarta adni a javításokat, amiből azért rengeteg volt.

Végül minden összejött. Majdnem egy éve vagyok itt és már megvan az első cikk az itteni munkák egy részéből. Ez azért nem rossz. Az, hogy a Nature Cell-ben jelent meg, csak ráadás.

Végre megjelent a Science Nature Genome Biology BMC Genomics cikk. Az egész úgy kezdődött, mint egy mese: Egy PhD hallgató töménytelen mennyiségű chip-seq illesztés nézegetése után furcsa anomáliára lett figyelmes: A CTCF kötőhelyek orientációja bizonyos szabályszerűséget mutat. Nem volt terabyte-os memória a gépében, nem használt agyonbonyolított matematikai modelleket, mégis valami olyasmit vett észre, ami a nagyok figyelmét elkerülte.

Többen is csatlakoztak a munkához, dolgozgattak és kezdett egyfajta kép kialakulni, amire eddig senki nem gondolt. De ha csak ennyi történt volna, a posztnak vége is lehetne. Magasabb szinten kisebb konfliktus kezdett kialakulni arról, hogyan is folytatódjon a munka. Egyik oldalon a még több kísérletet pártolták, míg a másik oldal elégségesnek érezte a bioinformatikai munkát a publikáláshoz. A pontos részletek nem voltak világosak előttem, mert mindez Debrecenben történt, de valahogy így képzelem el:

Amíg ment a civakodás, megjelent egy cikk, ami jó időre lehűtötte a kedélyeket. Ezt az időszakot a depresszió jellemezte.

Már nem emlékszem pontosan, mennyi idő telt el, de lassan kezdett feltámadni a remény, hogy bár sok mindent leírtak, talán még maradtak hiányzó részletek, amit érdemes lenne leközölni. Az önbizalom is visszatért, mert nem kevesebbet tűztek ki maguk elé, mint hogy a Nature-be közlik le az eredményeket.

Ami eddig történt, azt csak a kispadról követtem nyomon. Akkor kerültem játékba, amikor a volt főnököm megkért, írjak egy szimulációs progit, amivel azt néznék meg, hogy ha véletlenszerűen összekeverik a kötőhelyek sorrendjét, akkor is ugyan azt az eredményt kapjuk-e. A szerzők száma is emelkedett, mert ha a Nature-be közlünk valamit, nem árt, ha van valaki, aki már publikált oda és csinált már ilyen szimulációt.

A program maga nem volt egy nagy csoda, összekeverte az adatokat, majd megszámolta, hányszor jön ki a hipotézisnek megfelelő sorrend. C-ben írtam, így a Matlabhoz szokott emberek igencsak meglepődtek, amikor egy hónap helyett pár nap alatt lefutott. Ez persze lehetőséget teremtett rá, hogy a különféle - sokszor ad-hoc - ötleteket kipróbáljanak. Néha már nem is tudtam, kinek, mi a kívánsága, csak létrehoztam mindegyiknek egy branch-et és azon dolgoztam. GitHub elbírta.

A másik sarkallatos pont a modellt reprezentáló ábra volt. Itt is ment a vita, kinek melyik ábrázolás és színösszetétel tetszik.

A sok megfeszített munka után a kézirat eljutott a Nature-ig, ahonnan csont nélkül visszapattant. Ekkor kezdődött a görög mitológiát megszégyenítő huza-vona. Cikk bement valahova, majd visszajött, átdolgozták a szöveget, új kísérleteket elemeztek, az nem tetszett a rewiewernek, kivették az eredményeket, ismét beküldték. Komolyan nem tudnám felsorolni az összes állomást, de a kézirat valamelyik állapotában megjárta a Science-t, Genome Biology-t, végül a itt kötött ki. Ezt én újra a kispadról figyeltem, mert közben munkahelyet váltottam.

Végül Sziszüphosz köve felért a hegyre. Vicces, hogy mivel a szerzők között vagyok, a Sanger heti cikk ajánlójában, mint "Staff paper" szerepel, pedig minden, amit csináltam, Magyarországon történt.

Legutolsó Titines kalandom után a főnökség úgy döntött, keresnek valakit, aki megtaníthat rendesen exomot elemezni. Patrickre esett a választás, mert az ő eredményeire még a nagyfőnök Peter Campbell is elismerően füttyent.

Én az elején nem értettem, miért van erre az egészre szükség, különösen azt nem értettem, miért most és miért csak egy bizonyos projektnél jött ez elő, de úgy gondoltam, azért jöttem a Sangerbe, hogy tanuljak, ha pedig tanítani akarnak, nem szabad elzárkózni. Patrick sem értette pontosan, mit kívánnak tőle, de annak rendje és módja szerint eljött a megbeszélésre. Megjelent az egyik principális bioinformatikus is a csoportból, plusz két manager, akik az egészet kitalálták.

Arra kérték Patrick-et, mutassa meg, hogyan szokta elemezni az exomot, és lépésről-lépésre mutassa be az én adatszettemen. Patrick kinyitotta a laptopját és kivetített milliónyi titokzatosnak tűnő ábrát. Úgy éreztem, hogy itt valami valami olyat tanulok, hogy ha nem tapasztom be a fülem, a sok tudás azon fog kifolyni.

Patrick eltűntette az ábrákat és elkezdte bemutatni a lépéseket. Az első hasznos dolog egy előre megírt script volt, ami egy szekvenálási projekt összes VCF-jéből egy hatalmas táblázatot csinál, amiben minden minta minden adata szerepel. A VCF kriptografikus bejegyzései dekódolva külön oszlopba kerültek, amitől az egész sokkal átláthatóbb lett.

Ezt követően mindent betöltött egy Excelbe, amitől az arcomon megrándult egy izom, valahogy úgy, mint amikor Winnetou-t egy cölöphöz kötve kínozták ahol ez jelezte kínjai netovábbját. A táblázatot először a mutációt tartalmazó gének neve szerint sorba rendezte, megszámolta, hogy egy gén mennyi mutációt tartalmaz az összes szekvenált mintát egybe számolva. Csökkenő sorba rendezte a géneket a mutációk száma szerint, majd az első sort egy laza mozdulattal kitörölte, mert az volt a Titin, és mindig a Titin jön fel elsőre.

Patrick még beletekert a táblázatba, majd számomra teljesen ismeretlen géneket kijelölt és mielőtt megjegyezhettem volna a nevüket, kitörölte őket a táblázatból, mert azok hosszú gének és statisztikusan a hosszú gének több mutációt tartalmaznak. Végül összegyűjtötte a lista első 15-20 génjét és voila! Megvannak a driver gének! Én lopva a managerekre sandítottam, hátha valaki elröhögi magát, de nem tették. Őszintén szólva elkezdtem kényelmetlenül érezni magamat. Még mindig be akartam tapasztani a fülemet, de már nem azért, hogy a tudás ne távozzon, hanem, hogy ez a sok hülyeség be ne fészkelje magát oda.

Mi a gond a fenti módszerrel? Először is nem objektív. Akinek a zsebébe nincs egy mini-Patrick, az nem tudja mely géneket kell kitörölni. Ebből adódik a második probléma is: nem megismételhető. Ezt csak ez a kutató tudja megismételni. Ha publikáció lesz ebből, mit írok az Anyag és Módszerbe?

Ha ezt egy PhD hallgató adja elő, összecsavarok egy újságot és a fejére verek: "rossz, rossz, rossz". Ő viszont egy szenior kutató. Itt van már időtlen idők óta, én meg csak egy jött-ment kelet-európai vagyok. Végül is egy kutató intézetben vagyunk, talán észérvekkel rá tudok világítani a módszer hiányosságaira. Megkérdeztem, mi lenne, ha a találatok számát a gén hosszával normalizálnánk. Nem, az nem jó, mert elvesznek a rövid gének. Nem, mintha így nem vesznének el, de ráhagytam. Akkor azt kérdeztem, mi lenne, ha a szinoním-misszensz mutációk arányával kezdenénk valamit. Hiszen ahol több aminosav módosulással járó mutáció van, mint semleges, az nyilván fontosabb gén. Igen, ez így van, ezen Inigo dolgozik.

Ekkor két dolgot döntöttem el: szerzek szentelt vizet meg egy feszületet, hogy Patrickot távol tartsam magamtól és beszélnem kell Inigoval.

Egy labor megbeszélés után próbáltam beszélni vele. Sietett vissza a laborba dolgozni, de azt el tudta mondani, hogy a módszer lényege, hogy nem csak a gén hosszát nézni, hanem a kromatin állapotot, repeateket, meg még néhány paramétert. A szinoním mutációkkal egy negatív binomiális modelt készít és nézi, mennyire térnek el tőle a misszensz mutációk. Megkérdeztem néhány dolgot, amiből szerintem látta, hogy tök hülye vagyok, sietett is, ezért fogta a tollamat, a jegyzet füzetemet és a folyosón kb. 10 másodperc alatt odafirkantott egy fél R programot nyilakkal és matematikai jelzésekkel. Miközben írt, én éreztem, hogyan megyek össze. Mondta, hogy első sorban humánra készíti a programot, de kíváncsi, mit hozok ki egérre. Szabadkozott, hogy amit leírt nekem, az nem a teljes model, mert hiányzik belőle pár faktor. Mondtam, hogy szerintem még így is fényévekkel jobb, mint Patrick módszere. Ezzel egyet értett, majd otthagyott.

Három napig Wikipédiáztam, mire felfogtam a felét.

Észre sem vettem, hogy még egy cikkem megjelent. Őszintén szólva teljesen megfeledkeztem erről a munkáról, csak a mindent behálózó internetnek köszönhető, hogy ez az apró sziporka feledésbe nem merült.

Ez egy elég marginális projekt volt, régen is történt, ezért elképzelhető, hogy nem minden részletre emlékszem pontosan.

Valamikor 2014-ben kaptam egy bakteriális szekvenciát, hogy rakjam össze. Elég kevés információ volt róla és a legfontosabb jellemzője az volt: nem tudjuk, mi ez. Ráengedtem a Mirát, ami több ezer kontigba összes is fűzte. Játszottam egy keveset a paraméterekkel, de nem sikerült ezt a hatalmas számot lecsökkenteni. A GC tartalom viszonylag szélsőséges volt, feltételeztem ez állhat a probléma hátterében.

A Blast sem nagyon tudott rokon fajokat találni, de az egyik kontigban egy kizárólag Thermophilus fajokra jellemző enzimhez igen hasonló ORF bukkant fel és jobb híjján kijelentettük, hogy ez bizonyára egy Thermobifida faj. Közben a bioinformatikai csapat új taggal bővült és ez lett az egyik projektje,  így nekem nem is kellett tovább foglalkoznom ezzel.

Ezután jött az első meglepő fordulat. Egy Szeged melletti szekvenáló cég már előttünk összerakta a genomot 5 kontigba, beannotálták és rányomták a Kész pecsétet. Nem értettem, miért kellett nekünk időt és energiát pazarolni az összeszerelésre, ha az már készen volt ( ráadásul pénzért ), de majd látjuk, nem ez lesz az egyetlen meghökkentő ebben a projektben.

Azért annyi eredménye volt a Mira-s játszadozásnak, hogy kiderült, a cég agyondícsért összeszerelő módszere hosszú kontigokat hagyott ki a végleges eredményből, többek között a fent említett ORF-t. Ezt a cég is elismerte és gőzerővel nekiláttak a rendszer javításának. A kommunikáció ismét elhalt, nem hallottam új híreket. Csak a bioinformatikus kollega dolgozott az annotációval.

A gondok akkor kezdtek jelentkezni, amikor az új munkatárs egy posztert akart készíteni az eredményeiből. A PhD jelentkezéséhez kellett volna, mint publikáció. Ekkor tűnt fel a színen a kooperációs partnereink főnöke, a mikrobiológia koronázatlan királya. De ha ez mind nem is igaz, valószínűleg ezzel a gondolattal szokott aludni menni. Rögtön meg is mutatta, milyen nagy ember. Nem egy vele egy súlycsoportban lévő embert hívott fel, hanem a szegény PhD hallgató jelöltet és leordította a fejét, hogy hogyan merészeli az ő szekvenciáit leközölni.

A beszélgetésnek az indokolatlan én-vagyok-a-jani attitüd mellet volt egy másik nagyon hasznos hozanata. Kiderült, hogy az elemzést, szekvenálást a prof már leközölte (illetve valami posztert alkotott). Hurrá! Nincs is jobb munka a felesleges munkánál. A párbeszéd valószínűleg felsőbb szinten folytatódott, mert legközelebb már arról volt szó, hogy kapunk egy új szekvenciát, amit összerakhatunk és az csak a miénk lesz. Itt már kezdtem elveszíteni a fonalat, hogy most mi kooperáló partnerek vagyunk, vagy ellenségek?

Az utolsó fejezet a történetben, amihez még közöm volt, egy megbeszélés, amikor tőlünk le akarták küldeni a PhD hallgatót, hogy tárgyaljon ezzel a proffal és a szegediekkel a munkáról. Ilyen elavult technikák, mint Skype, GoToMeeting szóba sem jöhettek. Amolyan lelki támogatásnak én is mentem, mert ha telefonban ilyen kedves ez az ember, vajon mit csinálhat egy személyes találkozó alkalmával? Élve boncol?

Ezt már soha nem fogom megtudni, mert a megbeszélésen, amit ő kezdeményezett, nem volt jelen. A másik oldalon is hasonló kompetenciával és döntéshozó felelősséggel felruházott emberek voltak, mint mi. Ennek az lett a vége, hogy nagyon jól megértettük egymást, de érdemi lépések nem születtek, mondván, mindent meg kell beszélni a főnökkel.

Végül létrejött ez a cikk, de egy kéziratot nem kaptam, se olyan úri huncuttságot, mint köszönő levél. Végiggondolva, tényleg ezért ment a harc, hogy megjelenjen egy újságban, ahol a kutya sem fogja látni? Tényleg egyeseknek így kell érvényesülni a tudományban? Remélem ez volt az utolsó ilyen "kooperációs partnerem".

A csoportvezető hevesen dobogó szívvel nyitotta meg az e-mailt. Most végre kiderül, hogy elfogadták-e a cikket! A válasz rövid és lényegre törő volt. Bár nagyon udvariasan fogalmaztak, a cikket elutasították. A csoportvezető megnyitott egy új ablakot a gépén és elkezdte fogalmazni a levelet a többi szerzőnek.

Zsinórban a harmadik - gondolta, miközben ujjai automatikusan fogalmazták a szöveget. Ez a harmadik újság, ami képtelen megérteni az eredmény súlyát. Az idő pedig kevés. Most kell valami nagyot felfedezni, amíg kitart a pályázat és lelkesek a doktoranduszok. És amíg elég fiatal vagyok - szólalt meg váratlanul egy hang a koponyája hátsó szegeletében. Igen, közeledve az ötven felé, egyre kétségesebb, hogy hatalmas felfedezést tegyen, mert a növekvő adminisztráció, a pénz utáni hajsza minden kutatóból irodistát csinál. Irodisták nem tesznek felfedezéseket, csak aktákat tologatnak, aláírnak, iktatnak, mellékleteket töltenek ki, iratokat csatolnak más iratokhoz és próbálnak eleget tenni a többi irodista papír éhségének.

Nem, most kell feltenni életművére a koronát, amivel akár még akadémiai tagságot is nyerhet. A levél, amit a társzerzőknek írt, sokkal optimistább volt, mint a tények. Talán ő maga is elhitte a lelkesítő szavakat. Észre sem vette, hogy ugyan azokat a közhelyeket használja, mint két elutasítással ezelőtt.

Épp, hogy elküldte a levelet, amikor kopogtattak az ajtaján. Az egyik PhD hallgató volt, a csapat gerince. Az ő munkáján alapult az egész kutatás, ő fektette be a legtöbb energiát. A csoportvezető minden kérését teljesítette, méghozzá időben.

- Kaptam egy ajánlatot. A Baumann-csoportban kellene mutációkat elemezni - mondta az udvariassági formulák után.

- Még itt is rengeted munka van. Kicsit át kellene dolgozni a kéziratot, megtámogatnánk az eredményeket még több vizsgálattal, akkor biztosan el fogják fogadni. Nagyon jó lapba tudnánk leközölni. A legtöbb kutató teljesen rosszul közelíti meg ezt a kérdést. A mi hipotézisünk a jó.

- De az új kísérletek ellentmondanak neki. Most, hogy a módszerek pontosabb értékeket adnak, már nem látjuk olyan tisztán az eredményeket. Fél éve még megállta volna a helyét a hipotézis, de ma már nem.

- Azok teljesen rossz kísérletek, nem kell őket figyelembe venni. Az sem igaz, hogy pontosabbak a mostani eredmények. A régebbi adatokat kell keresni, azok a jók.

A PhD hallgató bágyadtan bólogatott. Nem vitatkozott tovább. Majd hozzátette:

- Két hónap múlva kezdek.

- Addig még rengeteg idő van. Összeszedem a gondolataimat, leírom, mit kell csinálni és ha meglesznek az eredmények, ismét beküldjük a kéziratot. Azt már nélküled is meg tudjuk csinálni, csak a vizsgálatok legyenek lezárva.

- Rendben.

Miután hallgatója elhagyta az irodát, a csoport vezető csak kicsit csüggedt. Nem baj - gondolta. Még van két másik ember, majd azok megcsinálják a szükséges elemzéseket. Közben újabb levele érkezett. A legutolsó pályázathoz csatolt B melléklet nem felelt meg a formai követelményeknek. Az új határidő péntek éjfél. Már majdnem felkereste a pályázat weboldalát, hogy elolvassa az új formai követelményeket, amikor megcsörrent a telefon. Az egyik professzor volt, akit eredetileg csak azért vettek be, mert megjelent egy cikke egy igen fajsúlyos lapban.

- Olvastam a leveledet. Úgy tűnik az összes magas impaktú laptól elutasítottak. Melyik újságot célzod meg?

- Még nem döntöttem, számtalan lehetőség van. Új vizsgálatokat fogok tervezni. Ez hihetetlenül nagy ötlet, két hónapja, mikor beszéltem Morrisonnal egy konferencián, ő is nagyon lelkes volt. Azt mondta, az eddigi eredményeink fele is elég lenne egy jó cikkhez.

- De az egészet elutasították. Háromszor.

- Sok nagyon jó cikket elutasítanak.

- Jó - zárta le a meddő vitát a professzor. Azért hívlak, hogy vegyél le a szerző listáról.

- Miért?

- Szerintem a leglogikusabb lépés az lenne, ha valami alacsonyabb impakt faktorú újságban közölnétek le. Én viszont nem akarok szerzőként szerepelni egy ilyen lapban. Egyébként sem érzem, hogy a hipotézis annyira jó. Minél többet gondolkodom rajta, annál több ellentmondást találok benne. Az új cikkek is egyre több részletet cáfolnak.

- Ezeket megbeszélhetnénk. Leírod az észrevételeidet és lépésről-lépésre átvesszük valamennyit...

- Már háromszor megtettük - vágott a szavába a prof - , de te makacsul kitartasz az eredeti elképzelésed mellett.

- Mert úgy van, látszik az eredményeken. Az az igazság.

- Ennek ellenére szeretném, ha levennél a szerző listáról.

Egy ideig még győzöködte a professzort, de az hajthatatlan volt. Udvariasan válltak el, de a csoportvezető mérges volt. Miért fordul mindenki ellene? Olyan sokat kér? Csak egy kis felfedezést akar tenni! Emlékezett mit érzett az első kísérletek kiértékelése után. Örömöt, mámort, mert minden érték összevágott, egy irányba mutatott. A hipotézis szinte kínálta magát. Akkor kellett volna megírni a cikket. Már nem is emlékezett rá, miért késlekedtek, de mire rászánták magukat, hogy leírják az észrevételeket, más kutatók teljesen ellentmondó képet kezdtek mutatni a jelenségről.

Lehet, hogy nekik van igazuk? Az anyagosztályról közben benézett egy nő.

- A rendeléseden a tételek összeget nagyobb, mint a havi kereted. Ki tudnál belőle venni pár dolgot?

- Mi a határidő?

- Háromkor el kell mennem, és még ma szeretném az összeset elküldeni.

- Jó, meglesz.

Rendelés és a pályázat formai követelményei. - gondolta. Mit is kéne csinálni a hipotézissel? A laborasszisztens kopogtatott.

- A szakdolgozók beszennyezték a puffert. Már háromszor csinálom meg a kísérletet és a pozitív kontrol sem működik.

- Biztos, hogy a szakdolgozók voltak?

- Csakis ők lehettek. Arra a vörös képűre gyanakszom.

- Ő két hete nincs itt.

Az asszisztens nem szólt semmit. A hallgatásával tartott ki hazugsága mellett. A csoportvezető túl jól ismerte már ahhoz, hogy tudja, észérvekkel nem megy semmire.

- Beszélek a szakdolgozókkal - ennyi elég is volt beosztottjának. Fölényes képpel távozott. A csoportvezető újra megpróbálta összeszedni gondolatait. Mit is kellene csinálni a kézirattal? Á, biztos, hogy jó a hipotézise! Nem kell azon semmit sem változtatni. Majd mások is meg fogják érteni a nagyszerűségét. Ismét megcsörrent a telefon. Gondolatának fonala újból megszakadt.

A nap végén, fáradtan ült a számítógép előtt, agyában próbálta összeszedegetni a gondolta-morzsákat, hogy elméletté ragassza őket össze. De minden próbálkozásra széthullottak. Ekkor mantra szerűen megismételte: cserben hagytak. Újra és újra nekilátott, hogy valami egységet teremtsen. Sikertelenül. Végül feladta a próbálkozást, csak a mantrát ismételte: cserben hagytak, cserben hagytak.

Bárcsak így kezdhetném ezt a bejegyzést: Ez is egy munka, amit valakinek el kell végezni. Van benne valami vagány és törvényen kívüli. Sajnos csak azt írhatom: Ez is egy munka, mindenki utálja, mégis mindenkinek el kell végezni. Ez nem más, mint a hivatalos ügyek bonyolítása Magyarországon.

Történt ugyanis, hogy a nulla forintba kerülő számlavezetési díj (ami már régóta nem nulla, de ezt ne firtassuk), hirtelen megugrott, többre, mint amit én hajlandó vagyok egy banknak fizetni, ezért a számlatípus módosítása miatt bementem a bankba.

Az egészet a családlátogatás idejére terveztem, ezért nem a lakóhelyem szerinti fiókot látogattam, hanem egy 200km-re lévőt. Számot húztam és utána vettem észre, hogy egy ismerős, Géza is a fiókban van. Ő nem húzott számot, mert ha bankba megy, csak és kizárólag Kriszta segítségét kéri és képes háromnegyed órát is várni, csakhogy Kriszta szólítsa. Ezért is történhetett meg, hogy én hamarabb sorra kerültem, mint ő.

Maga a hivatalos rész gyorsan ment. Odaadtam a lakcím kártyát, amiből látták, hogy nem sok közöm van a városhoz. Megnézték a tranzakciókat, ahol látták, hogy fizetés bizony nem jön a számlára, amiből egy kedves, udvariassági beszélgetés kezdődött.

- Látom nem jön a számlájára fizetés - kezdte a hölgy.

- Igen, mert külföldön dolgozom.

- Mit dolgozik?

- Kutató vagyok.

- Mit kutat?

- Rákkutatással foglalkozom.

Még kérdezett pár dolgot a kinti élettel kapcsolatban, majd elbúcsúztunk. Végig mosolygott, nagyon kedves volt. Én nagyon örültem, hogy végre nem egy olyan embert fogtam ki, aki utálattal végzi a munkáját és aki számára az ostoba és az ügyfél nem rokon értelmű szavak.

Géza, este a feleségével még meglátogatott minket. Elmesélte, mi történt a távozásom után. Az ügyintéző átment Krisztához és megkérdezte, hogy ismer-e engem, mert én nem is ebben a városban élek, előadtam valami mesét arról, hogy külföldön dolgozom, meg tudományos munkát végzek. Csakis ellenőr lehettem, semmi más.