Az élet kódjai

Kezdenek beérni a munkák. Hosszú pangás után beindult az impakt faktor gyár. Eddig ezzel a cikkel volt a legkevesebb problémám. Ez annak is köszönhető, hogy az első revízió után kapcsolódtam be a munkába.

A vizsgálatok során öt búzafajta kb. 20 metabolit szintjét mérték két évjáratban, három ismétléssel, két szövetben. SPSS-ben három táblázatra megcsinálták a MANOVA-t, de a bíráló kért még egy csomó statisztikai összehasonlítást, amit sajnos SPSS klikkeléssel nem lehetett megoldani. Legalábbis a bíráló adta időintervallumon belül nem.

Írtam egy nem túl optimális R szkriptet, ami így is 10 óra alatt lefutott és megcsinálta az összes összehasonlítást. Később kellett heatmapeket gyártani, de azok sem vettek el sok időt. Főleg, hogy PowerPointban még utólag maszatoltak rájuk.

Ez alatt az idő alatt tanultam meg, hogy különböző módon is ki lehet számolni a MANOVA-t. Természetesen a két statisztikai program máshogy számolja őket. Ez okozott némi fejtörést, mert nem tudtam azokat az eredményeket megismételni, amit az SPSS kiadott. Végül helyére kerültek a dolgok és megszülethetett ez a cikk.

Sok tekintetben a kutatás egyfajta versenyfutáshoz hasonlít, ahol az első helyezetten kívül nincs díjazás. Szerencsére elég sok versenyszám van, de így is tetemes mennyiségű kutató áll rajthoz. Hogy tovább növeljem a képzavart, néha csak akkor látjuk a konkurenciát, amikor az már célba ért és minket kiejtett a versenyből. Néha úgy érzem, egy blogot meg lehetne tölteni a hiábavaló próbálkozásokkal.

Ennek a cikknek az alapanyaga is majdnem így végezte. Én a de-novo összeszerelésben és az annotálásban segédkeztem. A mi részünkkel elég jól haladtunk, de a partnerek már nem voltak ennyire ambíciózusak. Egy levélváltás például heteket vett igénybe. A végén már úgy voltunk, hogy megírjuk magunk, a többiek pedig láttamozzák csak le.

Ekkor jött ki a konkurencia cikke. Nem emlékszem pontosan, de talán két-három hét depresszió után elkezdtük összehasonlítani a mi eredményeinket a friss cikkel és végül arra jutottunk, hogy van némi különbség a genomok között. Sajnos nem találtunk akkora különbséget, hogy az elemzések újdonságot nyújtsanak, de a genomok még leközölhetőek.

Kiválasztottuk az újságot is, de ekkor jöttek a drága partnerek extra kívánságai. Nevezetesen ne töltsük fel nyilvános adatbázisba, mert akkor jönnek a gonosz kínaiak, letöltik, kielemzik és megírják a cikket helyettünk. Az újság persze közölte, hogy a genom vagy nyilvános adatbázisban lesz, vagy nem lesz cikk. A partnerek így nagy duzzogva megengedték nekünk, hogy feltöltsük a szekvenciát, de kikötötték, hogy nem lehet látható, amíg meg nem jelenik a cikk.

Nem is volt semmi gond, egészen Karácsonyig. Ekkor ugyanis a partnere riadóztattak mindenkit, hogy a szekvenciáknak azonnal meg kell jelennie, mert ők jelentést, beszámolót, kivonatot írnak és ez nem lehet teljes a szekvenciák nélkül. Csakhogy, amit nem tudtak, hogy az NCBI-ban a feltöltött adatokat csak úgy lehet megváltoztatni, hogy küldünk egy levelet és megkérjük az adminisztrátort. Küldtem levelet, amire rögtön megérkezett a válasz: Szabadságon vagyok. Majd jött egy második levél is, amiben azt írták, tele vannak munkával, amint lesz szabad idejük, teljesítik a kérésem.

Szilveszterre megjelentek. Februárra a cikk is.

A korábbi Nanopore-os írásaim felkeltették az illetékesek figyelmét, valahogy összekapcsolták azokat az egyik munkatársammal és udvariasan figyelmeztették, hogy el kellene távolítani a blogbejegyzéseket. Szerencsétlen nem tudott az egészről semmit. Miután kiderült, hogy én voltam az elkövető, így kérték a tartalmak eltávolítását. Mivel nem akarom, hogy kidobjanak minket a programból, a kérésnek eleget tettem.

Most úgy érzem, olyan rosszfiús lett a blog. Itt olyasmit is lehet (lehetett) olvasni, ami tiltott információkat tartalmaz.

Mielőtt meglátogatnak a texasi nehézfiúk, gyorsan nézzük is meg, mások milyen információkat szivárogtatnak ki:

Kezdjük is mindjárt egy két órás borzalommal Nick Lomantől, akinek nincs time-lapse képes videokamerája:

De láthatunk nagyszerű programokat különböző folyamatokra: Vizualizációra, illesztésre, szekvencia javításra.

Cikkek is kezdenek megjelenni: HLA haplotípus meghatározásról, baci összeszerelésről.

Azt gondolom, a magyar demoscene ismét felszálló ágban van. 2010-ben két party volt csak nálunk. Function-ön négy demó indult, kettő 4k és kettő 64k introval. Elég nagy pangás volt, a depresszión egyedül az Experience segített, ahol megnézhettük az adott év legjobbjait és beszélgethettünk kicsit. Rákövetkező évben volt egy Busodore is a megszokott rendezvények mellett, de az csak egy fellángolás volt.

2012 érdekes fordulatot hozott. Az Experience belépett a partik sorába. Function-ön 11 demót nézhettünk végig. Egy évvel később csak egyel volt kevesebb demo, de már olyan nagy nevek is képviseltették magukat, mint a Fairlight.

Idén pedig még egy party lesz, a QB! A Cybernetic geneticsnek is van némi része benne, mert Betasector a szervezők között van. Ha a régi partik idén is megrendezésre kerülnek, az azt jelenti, hogy 2015-ben négy party várható. Csak győzzük release-el!

Egyesek úgy érezhetik, nem becsülöm eléggé az intézeti rendszergazdáinkat. Pedig rengeteget dolgoznak, hogy mi, hálátlan kutatók dolgozni tudjunk. Még a szórakoztatásunkról is gondoskodnak, hogy ne legyen olyan egyhangú az életünk. Legalábbis a következő eset erre enged következtetni:

Valami bürokrata kitalálta, hogy számba kell venni, hogy az intézetünkben mennyi nyomtató van és az egy év alatt mennyi papírt fogyaszt. Nosza, fel is kerekedett a két kópé, mert ugye egy ilyen bonyolult munkához nem elég egy ember. Ki is alakították a hatékony csapatmunkát. Az egyikük leolvasta a nyomtató típusát, IP címét (nevezzük Stannak), a másik beírta egy laptopba (legyen Pan).

Stan: Hogy kell előhívni a tesztoldalt?
Pan: Hosszan lenyomod a gombot.
Stan: Diktálom a sorozatszámot. Így, ahogy mondom: Iksz, kettő Negyven kilenc. Nem negyvenkilenc! Ahogy mondom: Negyven kilenc. Mondom, hogy nem negyvenkilenc! Negyven kilenc. Ezt nem hiszem el!
Én: Miért nem azt mondod neki, hogy négy nulla kilenc?
Stan: Igen, az lesz.
Pan: Itt a gép, írd be te.

Nem hiszem, hogy van még egy olyan bioinformatikai program, ami ennyire alapvető lenne, mint a Blast. Van egy elméletem, ami szerint egy ötlet eredetiségét úgy lehet lemérni, hogy hányan próbálják meg lemásolni, illetve a farvizén elevezni. A Blast ebben torony magasan vezet.

Kezdetek

Kezdetben vala a Smith-Waterman algoritmus és láták a bioinformatikusok, hogy ez jó. És volt szekvencia összehasonlítás, homológia keresés, első nap. Azután a sok szekvenciát elkezdték adatbázisokba gyűjteni, és hamar rájöttek, hogy a Smith-Waterman algoritmus sokáig tart, ha egy adatbázisban kell keresni. Ekkor született meg a Fasta, aminek a neve egy fájlformátumban köszön vissza. Ebből is látszik, hogy többféle módon válhat hallhatatlanná valaki. A Fasta három verziót élt meg, és 2000-ben nyugdíjazták. Én életemben egyetlen egyszer használtam, amikor egy gépen nem volt elérhető a Blast, akkor is csak demonstrációs célokból.

A hős színre lép

Amikor megjelent a Blast, még nem volt az a sziporkázó program, mint most. Nem volt képes gap-esen illeszteni, hiányzott belőle néhány statisztika, viszont kegyetlen gyors volt, miközben az érzékenység oltárán nem áldoztak fel sokat. A sebességre pedig égetően nagy szükség volt. A GenBank-ben abban az időben már 33 ezer szekvencia volt, ami nem tűnik túl nagynak, de akkoriban a gépek teljesítménye sem volt eget rengető.

A program lehetőségei viszont sokakat megihlettek. Blast dolgozik a RepeatMasker gépházában, az annotáló rendszerekben, mint amilyen a Trinotate is, de még HLA típizáló munkafolyamatokban is kap helyet. Ismeretlen fehérjék funkcióinak felderítésére az első lépés még manapság is az, hogy Blast segítségével megkeressük a rokon fajokban a szekvenciát és reménykedünk benne, hogy ott kísérletesen is ellenőrízték a fehérje szerepét (nem csak egy másik Blast kereséssel állapították meg azt). Egyszóval megtaláljuk mindenütt, ahol a szekvencia hasonlóság meghatározására van szükségünk. Gátlástalan cégek odáig merészkednek, hogy üzleti modellt építenek erre a remek kis programra.

Használata

A Blast parancssori kapcsolói rengeteget változtak a verziók során, és hála a különböző webes megoldásoknak, sokszor nincs is szükség az ismeretükre. Rendszeres használat esetén vagy ha nagy mennyiségű adatunk van, szükség lehet a Blast kézi futtatására. Ebben a leírásban a 2.2-es verzióval foglalkozom. Első lépés mindig az adatbázis építése. Ezt a makeblastdb paranccsal hozhatjuk létre egy FASTA fájlból. Meg kell adni a bemeneti állomány nevét, a szekvencia típusát (fehérje vagy DNS) és opcionálisan a kimeneti fájlok prefixét.

makeblastdb -in input.fasta -dbtype nucl -out mydb


Ezután jöhetnek a kérések. Az adatbázis és a kérés típusa határozza meg, melyik Blast programot kell futtatnunk:

A blastn programnak ezen felül három módja van: a megablast és a blastn-short és a dc-megablast. A megablast nagy mennyiségű kérés esetén gyorsabb, mintha többször lefuttatnánk a Blasttot, mert a kéréseket összefűzi egy szekvenciává. A blastn-short rövid (20 nukleotid) szekvenciák esetén adnak hatékony eredményeket. A -task paraméter segítségével aktiválhatjuk ezeket.

Az alapértelmezett paraméterek a legtöbb esetben elegendőek, olykor mégis szükség lehet azok állítgatására, hogy hatékonyabb, esetleg kevesebb eredményt kapjunk. Az első a -window_size. Ezzel állíthatjuk be, hogy mikor kapcsoljon össze két közeli találatot a blast. A -word_size segítségével állíthatjuk a legkönnyebben a program érzékenységét. Minél magasabbra állítjuk, annál nagyobb összefüggő, teljesen illeszkedő szakaszokat fog megtalálni. Tehát gyorsabb fog futni, de kevesebb találatot kapunk a kevésbé hasonló szekvenciákból.

A -matrix segítségével azt határozhatjuk meg, mennyire tekintsünk hasonlónak két monomert. Ez a beállítás nagyon függ attól, mire is akarjuk használni a Blastot és ha elrontjuk, ezzel okozhatjuk a legnagyobb kárt.

Ha nem érdekelnek minket a gapek, akkor az -ungapped segítségével megszabadulhatunk minden ilyen beállítástól. Főleg rövidebb szekvenciák esetén érdemes használni. Ellenben ha irányítani szeretnénk a gapek hosszát és számát, akkor a -gapopen és -gapextend segítségével bírálhatjuk felül az alapértelmezett viselkedést. Az algoritmus szempontjából ide kell venni a -penalty és -reward opeciókat is. A szekvenciák összehasonlításánál gyakran többféle módon is összeilleszthetünk két szekvenciát. A következő, erősen sarkított példa is ezt kívánja szemléltetni:

Az illesztés paramétereire nem térnék ki, mert rengeteg weboldal és fórum foglalkozik velük. A kimenet feldolgozását viszont valahogy elmúlasztják bemutatni. Az alapértelmezett kimenet jó vizuális áttekintésre, de sok eredmény esetén nehéz a feldolgozásuk. A legegyszerűbb ilyenkor táblázatos formát kérni (-outfmt 7 vagy -outfmt 6, attól függően, hogy akarunk-e kommenteket, vagy nem). Ha több információt szeretnénk visszakapni, az XML lehet segítségünkre. XML-t szinte valamennyi programozási nyelven fel lehet dolgozni. Azt is megadhatjuk, hogy táblázatos kimenet esetén milyen mezőket kapjunk vissza.

from xml.dom.minidom import parse
import sys
xml = parse(sys.argv[1])
for hit in xml.getElementsByTagName('Hit'):
    hitacc = hit.getElementsByTagName('Hit_accession')[0].firstChild.nodeValue

A fenti Python kód kigyűjti a találatok szekvencia azonosítóit.

Habár a nukleotid alapú Blast nagy népszerűségnek örvend, a fehérje alapú homológia keresés a gyakorlatban sokkal lényegesebb. Mivel különböző trinukleotidok is kódolhatják ugyan azt az aminosavat, ezért a fehérje alapú kereséssel olyan hasonlóságokat is megtalálhatunk, ahol az evolúciós távolság nagyobb. Nem véletlen, hogy fehérje alapú keresésre többféle Blast program létezik.

A blastp sok tekintetben megegyezik a blastn-el, ezért az ott leírtak itt is alkalmazhatóak. A psi-blast ellenben egy teljesen más keresési stratégiát valósít meg. Szekvencia helyett ugyanis mátrixokkal keres. Míg a nukleotid alapú összehasonlításnál csak azt nézzük, hogy a szekvenciák egy ponton megegyeznek-e vagy sem, addig a fehérjék összehasonlításánál a nagyszámú kémiai jellemző miatt árnyaltabb hasonlósági mutatókat kell megállapítani. Erre szolgálnak a mátrixok. Minél több hasonló szekvencia kerül a mátrixba, annál több információnk van arról, hogy a szekvenciák mely pozíciói konzerváltak, tehát az összehasonlítás során lényegesek, és melyeknél van nagy diverzitás. De hogyan lesz egyre több elemünk a mátrixban? A psi-blast ezt iterációval oldja meg. A találatokat felhasználva új mátrixot képez és megismétli a keresést. Parancssorban a -num_iterations kapcsolóval szabályozhatjuk ezt.

A psi-blast minden iteráció után egyre távolabbi hasonlóságokat képes megtalálni, így előfordulhat, hogy végül olyan találatokat is megkapunk, aminek kevés köze van az eredeti kereső szekvenciához. A phi-blast ezért egy szabályos kifejezés-szerű mintázattal csökkenti ezen találatok számát. Parancssorban a phi_pattern opcióval adhatunk meg egy fájlt, amiben definiálhatjuk a mintázatokat. Ha a weben keresünk, csak egy mintázatot használhatunk. A szabályos kifejezés szintaxisáról itt olvashatunk.

A psi-blast egyik gyengesége, hogy a mátrix egy blastp keresés első találatából származik. Ezt a hiányosságot igyekszik kiküszöbölni a delta-blast. Ennél a programnál először a konzervált domain adatbázisra történik egy illesztés, majd ebből állítja elő a mátrixot.

Futtatási módszerek

Blastot nagyon sokféle módon futtathatunk. Ha van egy böngészőnk, akkor csak annyi a dolgunk, hogy felkeressük a számtalan weboldal egyikét. Ez rendkívül kényelmes és egyszerű módja a keresésnek. Hátránya, hogy sok limitációval kell számolnunk. Leggyakrabban a kereső szekvenciák számát és méretét korlátozzák.

Ha nincs böngészőnk (például mert egy távoli gépre jelentkeztünk be parancssorban) vagy szeretnénk kicsit automatizálni a kereséseket, akkor az URL API lehet segítségünkre. Ebben az esetben egy URL-be írhatjuk be paraméterként a program beállításait. A folyamat két lépcsős. Először elküldjük a kérést, kiszedjük a Request ID-t (RID), majd ennek ismeretében letöltjük az eredményt. Mivel ebben az esetben nincs automatikus oldal frissítés, ezért ha túl kevés idő telik el a kérés elküldése és az eredmény letöltése között, csak egy értesítést kapunk. Ugyan csak ügyeljünk rá, hogy ne terheljük le a szervert túl sok kéréssel. Ezzel csak azt érjük el, hogy letiltanak bennünket. Minimum a következő paramétereket kell megadnunk:

 wget "http://www.ncbi.nlm.nih.gov/blast/Blast.cgi?QUERY=145361606&DATABASE=nr&PROGRAM=blastn&CMD=Put" -O rid.html

A kérés az Arabidopsis AGO5 mRNS-ét küldi el. A QUERY mezőbe a GI számot írtuk be. Az eredményt a következő utasítással kaphatjuk meg (figyelem, a RID kérésenként változik!):

wget "http://www.ncbi.nlm.nih.gov/blast/Blast.cgi?RID=B5ZDS8C2015&CMD=Get" -O result.html

A paraméterek teljes listája itt található.

Akit a GET-es paraméterek limitációi aggasztanak, használhat SOAP-ot is. Ezt használják a klikkelős programok nagy többsége is. Példaprogramokat itt találunk. Ha a klikkelős programokat választanánk inkább, szóba jöhet a CLC Workbench programcsalád legtöbb tagja, a Geneious, de akár az ingyenes UGene vagy az NCBI Genome Workbench is.

A végére hagytam a legegyszerűbb módszert. A parancssoros blast program a -remote kapcsolóval távoli feldolgozást kezdeményez. Helyi használatra a poszt elején láthattunk példákat. Ha számítógépünket nagyon lefoglalják egyéb programok, használhatunk célhardvereket is. Ezek többnyire FPGA alapokon nyugszanak.

Technikák

A Blast legegyszerűbb, mindenki által ismert használati módja, hogy elküldünk egy szekvenciát és nézzük, milyen találatokat kapunk. Ortológok keresésénél szokták használni a reciprok keresést. Ez két keresésből áll. Először egy "normál" keresést hajtunk végre, majd a legjobb találattal ismét végrehajtunk egy keresést egy olyan adatbázison, amiben az előző kereső szekvencia is szerepel. Ha az első helyen visszakapjuk az eredeti szekvenciát, a két szekvenciát 1-1 ortológnak kiáltjuk ki.

Új organizmus transzkrip annotálásnál, ha a blastn eredmény nem kielégítő, tblastn-t is lehet használni. A fehérje szekvencia konzerváltabb, mint a DNS, ezért esélyesebb, hogy jó eredményt fogunk kapni.

Vannak esetek, amikor a Blast erőssége (lokális illesztés) egyben a hátránya is. Aki sok keresést futtatott, találkozhatott azzal a jelenséggel, hogy túl sok HSP-re esett szét a találat. Ha nem akarunk másik illesztő programot használni, jó szűrési módszer, hogy csak azokat a HSP-ket tekintjük egy találatnak, amelyek azonos orientációban vannak (természetesen a HSP-k közötti távolságot limitáljuk).

Végszó

A Blast hosszú ideje hű társa a bioinformatikusoknak és még az is marad egy jó ideig. Ezzel a poszttal szeretnék tisztelegni az alkotóik előtt és kívánok nekik még ezer hivatkozást.

Intézetünknek valami különös vonzása lehet, mert akik egyszer elhagyták, valami úton-módon visszatérnek. Nem történt ez máshogy a Sírós kislánnyal sem. Mindent hátrahagyva elment banki asszisztensnek és úgy tűnt a tudományt ismét hatalmas veszteség éri. Mivel még nem volt meg a diplomája, visszatért, hogy két hónap alatt megoldja ezt a problémát és MsC-vel felvértezve elmenjen Németországba PhD-zni.

A visszatérés nem ment zökkenő mentesen. Először is képtelen volt egy távoli gépről adatokat letölteni. Az scp-vel kinti gépről akarta a tűzfal és millió router mögött elhelyezkedő munkaállomását elérni. Pedig az infrastruktúra mit sem változott, mióta elment (még a felhasználói fiókja is megvolt a távoli gépen). Az említett távoli gép egyébként egy másik egyetem tulajdonában van, de mivel a csoportunk vezetőjének ott is van állása (és ő a gép egyik rendszergazdája), ezért használjuk. Pédának okáért ott tároljuk a nyers szekvenálási eredményeket is.

Ez az állás sajnos megszűnt, de a kapcsolat megmaradt és továbbra is úgy használjuk a gépet, mint eddig. Ezt a Kislánynak is megemlítettük, aki viszont nem egészen így adta tovább a nedves laboros kollégáknak. Alig fél órával később megjelent két másik csoport vezetője és nekünk estek, hogy most mi lesz az ő szekvenciáikkal, mert le akarják törölni a távoli gépről. Hiába magyarázták nekik, hogy nem kell pánikolni, mert van biztonsági mentés nálunk is, a szervert továbbra is használhatjuk, csak egy állás szűnt meg. Az érveket meg sem hallották, csak hajtogatták, hogy az ő adataikat törölni fogják. Olyan volt az egész, mint az Inception. Elültettek egy gondolatot a fejükben, ami túlbúrjánzott.

Később kiderült, hogy ők is elkezdtek biztonsági mentéseket csinálni az egyik PhD hallgató laptopjára. Pár nap múlva felkerestek egy másik csoporttól is, hogy egy USB-s vinyóra mentsek le "mindent".

Egyik nap közölte, hogy őt nem csak azért vették vissza, hogy megcsináljon bizonyos elemzéseket, hanem azért is, hogy bioinformatikát oktasson. Azzal táskájából elővett egy tabletet és elindult tanítani. Ezt már csak azért sem értettem, mert a múlt év végén tartottunk bioinfó oktatást.

Annyi biztos, mióta itt van, nem unatkozunk. De van egy olyan érzésem, azután sem fogunk, hogy ő elmegy.

Először is válasszunk egy programot, ami a cikkek és fórumok tanúsága szerint könnyedén megoldja az Ön összes problémáját. Például az EuGene-t, ami a leírasok szerint annotálja az Ön frissen összerakott genomját. Telepítse a programot, ami olyan rendkívül hasznos és nélkülözhetetlen függőségekkel rendelkezik, mint a a4wide LaTeX stílusfájl, ami csak plusz 200Mb egyéb eszközzel válik elérhetővé.

Mélyedjen el a dokumentációban és fedezze fel, hogy bizony az igazán hasznos funkciók eléréséhez további programokra lesz szüksége. Például NetGene2 és NetStart programokra. Mindkét programot csak e-mail útján szerezhetjük be, ahol bizonyítjuk, hogy nem vagyunk gonosz cég, akik profitot akarnak. Sajnos a NetStart bináris, ezért a telepítésével még úgy is érezhetjük magunkat, hogy haladunk és célba fogunk jutni. Szerencsére a NetGene2 nem ringat minket hiú ábrándokba. A forráskódja ugyanis 2001 óta változatlan, esély nincs rá, hogy turkálás nélkül működjön. Nosza, álljunk neki! Keressük meg az összes makrót és függvény definíciót, ami ütközik a szabvány C++ matematikai és sztring könyvtárakkal. Gyomláljuk ki a GCC elavult kapcsolóit a Makefile-ból.

Úgy látom néhányan elégedetten hátradőlnek, hogy készen vannak. Csak ne olyan sietősen! Tesztelték a programot? Nem működik a programhoz mellékelt teszt adatokkal sem? Bingó! Floating point exception? Bingó! Most akkor lehet gondolkodni: A mi gányolásunk rontotta el? Rossz a program? Valami függőség változott az elmúlt 14 évben? Hétfőn beszámoló az eddigi munkáról? Kellemes hétvégét!

De addig is fordítsa le ismét a programot debug módban, gdb-vel keresse meg a hiba helyét és szörnyülködjön el! A hiba ugyanis a szekvencia index kezelő részben van! Miután kijavította a hibát és ellenőrizte, hogy az eredmény ugyan az, mint a webes verzióban, akkor indítsa el az összeszerelt eukarióta genomján is. Lepődjön meg Ön is, amikor megpillantja a program limitációit: maximum 1500 darab 1 millió hosszú szekvencia. Tehát a programmal nemhogy egy eukariótát, de még egy nyamvadt E. coli genomot sem lehet feltérképezni.

Miután végérvényesen zsákutcába jutott, gondolkodjon el azon, hogy ezek az emberek mennyi impakt faktort, kutatási támogatást és idézettséget zsebeltek be, hasonlítsa össze a saját eredményeivel és csuklassa meg a szüleiket. Esetleg nézzen szét a neten, keressen Önmagánál is nagyobb lúzereket és röghögje ki őket.

A munkám és a hobbim látszólag nagyon különböző entitások, de minél többet foglalkozom velük, annál több hasonlóságot fedezek fel közöttük. Erről a nemrég lezajlott Magyar Bioinformatikai Társaság közgyűlése győzött meg végérvényesen. Igaz, a Magyar Demoscene Egyesületnek (a link még nem működik) nem vagyok tagja, de a levelezési listán fenn vagyok és értesülök minden fontosabb dologról. Röviden összefoglalom, miért gondolom olyan hasonlónak a két csoportosulást:

• Mindkettő számítógépes tevékenység
• Mindkét tevékenység nagyfokú hozzáértést kíván
• Mindkét tevékenység nagyon szerteágazó
• A szerteágazóság miatt nehezen definiálhatóak (gyakorlatilag még a tagok is eltérően vélekednek)
• Mindkét szervezet tagjai eléggé passzívak
• A tagok nem, vagy csak kis százaléka fizet tagdíjat
• A vezetőség nincs tisztába a társaságra vonatkozó jogszabályokkal
• A vezetőség csak minimálisan foglalkozik a társasággal/egyesülettel (mentségükre legyen mondva, ezt legalább bevallják)
• A tagok csak kis százaléka látogatja a közgyűléseket
• A tagok csak kis százaléka van fenn a Facebookon/Twitteren

Röviden ennyi. A legnagyobb baj, hogy én is csak a hiányosságokra tudok rámutatni, megoldást nem tudok. De talán kezdetnek jó lenne, ha befizetném a tagdíjat.

Mentségemre legyen mondva, hogy a számlaszám, amire be lehet fizetni a tagdíjat, a társaság weboldalán van, amire nem lehet regisztrálni. Korábban a befizetések a társaság által szervezett konferencián történtek, de ennek megszervezése idén elmaradt.

Grassal volt találkozóm. Egy szálloda előtt álltam, amikor észrevettem, hogy milyen érdekes objektumok vannak egy busz oldalára festve. Azután a képleteket vettem észre. Sugárkövetés a busz oldalán! Ezzel kívánok Boldog Új évet minden scenernek.

Elérkeztünk a burn-in lépéshez. Ennek során egy ismert szekvenciájú lambda fágot kellett megszekvenálni. Ez még a teszt része és a protokolok begyakorlására is kiválóan alkalmas. Mivel nálunk két készülék is van, elég adatot tudtam gyűjteni az elemzésekhez és alaposan begyakorolhattam, mire is kell klikkelni. Sőt, a pipettázásból is kivettem a részemet.

A könyvtár készítés egyértelmű a leírások alapján. A teljes protokollt felesleges itt részletezni, mert úgyis fantázianeveket tartalmaz (pl. motor fehérje), valamint folyamatosan változik. Volt is ebből félreértés, mert kinyomtatták a protokollt, a neten pedig időközben frissítettek. De még olyan is előfordult, hogy a kereszt hivatkozások eltérő módon frissültek, és megnehezítették a szöveg értelmezését. Ellenben felvettem mindent, a videó megtekinthető itt. Ez nem az a marketing szagú anyag, ahol előre beállított pipettákkal egy steril (vagyis használaton kívüli) laborban egy jól fésült ember végzi a lépéseket. Ez kérem a valóság: Kupleráj, szervezetlenség és hibák:

A második rész:

A minta felvétele után 6 órán keresztül ment a kis gép. A belső fórumon panaszkodtak, hogy a szekvenáló képes túlmelegedni, ezért a légkondícionálót is bekapcsoltam, amitől a hőmérséklet stabilan 37 fok volt. Mivel számítógép vásárlási igényeinket rendre visszadobják, ismét saját hardverrel támogattam a magyar kutatást. A szekvenálást is megtekintheti mindenki:

Ezzel el is érkeztünk a szekvenciákhoz. A fast5 fájlok feldolgozásához immár Loman csoportja eszközt is ad poretools néven (és sikerült megakadályozniuk, hogy az általam fejlesztett Fast5 Studio legyen az első). A cucc jó, a samtools hagyományait követi, de a gyors fejlesztésnek hála annyi hülye függősége van, hogy Ubuntun kívül nem bírtam másra feltelepiteni. (Pontosabban az első olvasás után elment a kedvem a próbálkozástól) A fast5 fájlokban 1 és 3 közötti szekvencia található a leolvasás minőségétől függően. A 2D leolvasás során ugyanis a két szálú DNS-t széttekeri és külön leolvassa az egyik szálat (template), majd a másikat (complement), végül generál egy konszenzust is (twodirections). Különböző, a szekvenálások során fellépő hibáktól függően egyik-másik szekvencia hiányozhat.

A readek hossza Poisson-eloszlást követ, nálunk a várható érték mindkét szekvenálás esetén 3000 nukleotid volt, a leghosszabb pedig elérte a 78 ezer hosszúságot. A readek száma függ az úgynevezett pólus számtól. Ez gyakorlatilag azt mondja meg, hány szekvenálás történhet párhuzamosan. A flowcell elméletileg 512 pólussal érkezik, a gyakorlatban az első szekvenálás esetben 267, a másodikban 400 pólus volt aktív. Mondanom sem kell, a négyszáz pólusos sikerült jobban.

Elméletileg a flowcell egy lemosást követően újra használható, de a nálunk járt példányok esetén a pólus szám harmadolódott és ezzel a hatákonyság is. Több módszert is kipróbáltunk, de a pólusok működés képtelenné váltak. (Időközben a fórumon egyesek a pólusok megmentésére tettek próbálkozásokat).

A readek nagyon sok hibát tartalmaznak. Átlagosan minden 3-4 nukleotid hibás, és vannak indelek is. Ami viszont érdekes, hogy a szekvencia hosszával a hibák száma nem korrelál. Kapunk itt is megbízhatósági pontszámot (quality score) minden egyes nukleotidra, de a gyakorlat azt mutatja, hogy nem jelent semmit. A hibák előfordulási aránya nem mutat összefüggést ezzel a pontszámmal. Egy illesztést itt láthatunk:

Illesztésre a Last-ot szoktuk használni, erősen megengedő módban. A hosszú szekvenciáknak köszönhetően ez mégsem probléma. Fórumon többen is összehasonlították az elérhető illesztőprogramokat, készítettek egyedi mátrixot is, hogy növelhessék a hatékonyságot, de eddig a Last tartja magát. (Azóta Ivan Sovic fejlesztett egy saját gráf alapú illesztő programot, de még nem teszteltem)

A hibákat elemezve találunk homopolimer hibát, ami nem meglepő, tekintve, hogy a DNS áthúzása a póluson valószínűleg nem konstans és a pólus konformáció változása is nehezen érzékelhető azonos nukleotidok esetén. 

De-novo összeszerelés eddig kivitelezhetetlen. Illuminával történő hibrid assembly viszont ígéretesnek tűnik a SPAdes program használatával, ha a minion readeket PacBio-ként adjuk be. Erről már cikket is adtak ki.

Rokonoknál találtam ezt a kazettát. Ami miatt érdekes, hogy a felirat tanúsága szerint Atari 1040 ST-vel készült. Az már csak plusz ráadás, hogy Karácsonyi ének a címe. Ezzek kívánok Kellemes Ünnepeket olvasóimnak.

A tudományos publikációk tárolása és az ott található információk visszakeresése alapvető fontosságú igény minden kutatónak. Selye egy egész fejezetet szentel katalógus rendszerének bemutatására. Manapság a PDF és az elektronikus kütyük világában mindez nevetségesnek tűnhet, de a probléma manapság is jelen van.

Számtalan online megoldás létezik: Mendeley, PubMed, ScienceDirect, stb. Ez teljesen jó a formális csatornákon keresztül megszerezhető cikkeknél. A cikkek egy részéhez viszont informális módon jutunk hozzá: például bírálat formájában. Jó lenne úgy keresni ezekben a cikkekben is, hogy ne kelljen kiadni a fájlokat a kezünk közül.

Eddig egy meglehetősen primitív, de éppen ezért nagyon hatékony rendszert használtam. A cikket letöltöttem PDF-ben, a fájlt a PMID számmal neveztem el, majd a PubMedről letöltöttem szövegként az absztraktot és PMID + txt névvel láttam el. Ha kíváncsi voltam valamire, grep-el megkerestem az absztaktot, majd elolvastam a hozzá tartozó PDF-et.

A rendszer alapvetően működött, de nem tudtam keresni a cikk szövegében, a grep nem kedveli az elírásokat (már pedig ha nem emlékszem pontosan egy kifejezésre, akkor rosszul keresek rá), az informális cikkeket továbbra sem találom. Végezetül meg kell említeni, hogy nem minden absztrakt található meg a PubMedben.

Az egyik megoldás a Lucene és a PDFBox. A Lucene egy szöveg indexelő és kereső rendszer. Java alapú API-val rendelkezik. A PDFBox, mint neve is mutatja egy PDF kezelő könyvtár. A két API-t a leírások alapján könnyű integrálni. De ha minden szép és jó lenne, akkor ez a poszt nem született volna meg...

Jelen poszt a Lucene 4.9.0 és a PDFBox 1.8.6 verziókat mutatja be. Mavennel a fordítás nem okoz gondot, de amint együtt akarjuk használni a kettőt, már problémákba ütközünk. Legalábbis a dokumentációban bemutatott kód nem működött. A PDFBox egységtesztjében egy régi Lucene verzió volt, amihez már Java API sincs a neten.

PDFBox

A PDFBox feladata csak annyi, hogy a PDF állományt beolvassa és kibányássza a szöveget. Ezt négy sorból meg lehet csinálni:

PDDocument pdf = PDDocument.load(f);
PDFTextStripper totext = new PDFTextStripper();
String fulltext = totext.getText(pdf);
pdf.close();


Lucene

A Lucene használata viszonylag egyszerű. Létre kell hozni egy indexet, bele kell tölteni a dokumentumokat, majd keresni kell az indexek között. Az index létrehozása sem bonyolult:

Analyzer analyzer = new StandardAnalyzer(Version.LUCENE_4_9);
IndexWriterConfig conf = new IndexWriterConfig(Version.LUCENE_4_9, analyzer);
conf.setOpenMode(IndexWriterConfig.OpenMode.CREATE_OR_APPEND);
IndexWriter index = new IndexWriter("/tmp/luceneindex", conf);

Ahol az igazi móka kezdődik, az a szöveg beillesztése. Ugyanis, akár csak egy adatbázis esetén, itt is lehetőségünk van a szöveget mezőkbe szétosztani. Például létrehozhatunk egy mezőt az absztaktnak, az eredményeknek, stb. Ezzel a későbbi kereséseket tudjuk finomhangolni. Tegyük fel, hogy a fulltext változót felbontottuk fejezetekre és most ezekből készítünk egy dokumentumot, majd adjuk hozzá az indexhez:

Document doc = new Document();
doc.add(new StringField("url", url, Field.Store.YES));
doc.add(new TextField("abstract", abstract, Field.Store.YES));
doc.add(new TextField("methods", methods, Field.Store.YES));
doc.add(new TextField("references", ref, Field.Store.YES));

index.addDocument(doc);


A visszakeresés már gyerekjáték. A példa megkeresi azokat a dokumentumokat, amelyek tartalmazzák a "bioinformatic" és "database" szavakat az absztraktjukban:

dir = FSDirectory.open(new File("/tmp/luceneindex"));
dirread = DirectoryReader.open(dir);
index = new IndexSearcher(dirread);
analyzer = new StandardAnalyzer(Version.LUCENE_4_9);
QueryParser parser = new QueryParser(Version.LUCENE_4_9, "abstract", analyzer);
Query q = parser.parse("bioinformatic AND database");
ScoreDoc[] hits = index.search(q, 1000).scoreDocs;
for(int i = 0; i < hits.length; i++){
  Document pdf = index.doc(hits[i].doc);
  System.out.println(pdf.get("url"));
}
dir.close();
dirread.close();

A Lucene természetesen ennél többet is tud. Lehetőség van a keresett szóhoz hasonló szavak keresésére, a találatokat rendezhetjük, több keresés eredményét összevonhatjuk. Akit elrettent a sok kód, azoknak a Solr jelenthet segítséget.

Simándi Zoltán, Nagy László: In vitro neuron, in silico PRMT8, in vivo glioma

Ebben a bevezető jellegű előadásban azt boncolgatták, a megtermékenyített petesejt hogyan differenciálódik idegsejtekké. Az RNA-seq vizsgálatokkal találtak egy PRMT8 gént, ami a központi idegrendszerben fejeződik ki. Kiütötték a gént, aminek hatására a sejtek továbbra is képesek voltak idegsejtté differenciálódni, de a sejt expressziós mintázata megváltozott. A génhálózati vizsgálatok kimutatták, hogy a PRMT8 a sejt elektrofiziológiás állapotáért felelős géneket, az asztrocita útvonalban részt vevő és neurodegeneratív betegségben szerepet játszó géneket szabályoz.

Réthelyi János: Bioinformatikai módszerek a skizofrénia-kutatásban: RNS- szekvenálás és konnektomika

A skizofrénia tünetei: Halucináció, téveszmék, érzelmi elsivárosodás, anhedónia, kognitív zavar. Periodikus lefolyású, de a tünetek minden periódus végén súlyosbodnak. Jelenleg a dopaminerg receptorok szelektív gátlásával gyógyítják, de kezelés sikeressége egyénenként változik. A betegség öröklődik, valószínűleg poligénes, komplex gén-gén és gén-környezet interakciókat figyeltek meg. A GWAS vizsgálatok érdekessége, hogy a variációk nagy része az MHC I régióba esik. A skizofrén egyén genomjában nagyobb arányban fordulnak elő mikrodeléciók és mikroduplikációk. Találtak de-novo mutációkat is kromtain átrendező faktorokban, szinaptikus funkciók génjeiben. A helyzetet tovább bonyolítja a neuronok eltérő genetikai állománya, a mozaicizmus is. A retrotranszpozon aktivitás is erősebb a betegek körében. Létrehoztak egy adatbázist is Schizobank néven, ahol a páciensek exom szekvenálásait teszik hozzáférhetővé.

Az előadás második részében IPS őssejtek segítségével in vitro agyi folyamatok modellezését mutatta be az előadó. A kísérletek korai stádiumban vannak, jelenleg egy úgynevezett pszeudo-neuron differenciációig jutottak, amely már képes akciós potenciált kiváltani, de a valódi neuron teljes funkcionalitását még nem éri el.

Pulay Attila: Multimarker vizsgálómódszerek a pszichiátriai genetikában

Az előadás bemutatta a neurológiai betegségek genetikai azonosításának problémáit. Az első nehézség a helyes diagnózis megállapítása. Sok tünetet csak a páciens visszaemlékezéseiből lehet megállapítani. A szakemberek dolgát tovább nehezíti, hogy sok pszichiátriai kórkép mutat hasonló tüneteket. Történtek próbálkozások objektív diagnosztikai  bélyegek azonosítására (ezekre az endofenotípus névvel hívatkoztak), de ezek értelme a betegség függvényében kevésbé meghatározott. Az állatmodellek korlátozottan használhatóak. A genetikai háttér azonosítását nehezíti, hogy sok páciens viselkedésével a hajlamosító környezetet is "átörökíti". Négy kutatási irányt vázoltak fel: A nyers erő módszerét, amikor a minta elemszám növelésével akarnak gyenge asszociációt találni. A ritka variánsok keresése a második, míg a környezeti faktorok integrálása a harmadik módszer. Végezetül az adatbányászati eljárások alkalmazása a manapság legdivatosabb irány. A vizsgálatokhoz a következő programok használhatóak: GSEA, sigPathway, KGG, David, NetGSA, Pathway Express.

Grolmusz Vince: Gráfelmélet és az agy

Az előadás egy magyar konnektóm adatbázisról szólt, ami az agy egy olyan gráfelméleti leképezése, ahol a csúcsok a neuronokat, az élek pedig a szinapszisokat reprezentálják. Mivel jelenlegi ismereteink nem teszik lehetővé, hogy akár a Drosophila konnektómot modellezzünk, ezért úgynevezett ROI-kat használnak, ami neuronok egy csoportját jelöli. Hogy pontosan milyen csoportokat is takar, azt leginkább egy, az előadó szájából elhangzó mondat szemlélteti: "Azért szeretem [a ROI-kat], mert meg sem próbálja érzékeltetni, hogy itt anatómiai egység van".

A magyar konnektóm adatbázis itt érhető el. Az adatbázis segítségével rengeteg összehasonlításra nyílik lehetőség. Az előadás felvázolta, milyen különbségek lehetnek az idős és fiatal agy között, valamint a férfiak és nők között. Eredményeik többek között, hogy a nők agya jobb expander, mint a férfiaké, valamint kromatikus számszerűség kisebb idősebbek és nők esetében.

Tóth Brigitta: Agyi funkcionális kapcsolatok vizsgálta gráf elméleti elemzéssel

Itt a kutatók a EEG-vel meghatározták az agy funkcionális területeit. Akkor tekintettek funkcionális egységnek két területet, ha neurális aktivitás hasonló oszcillációt mutat. Az így detektált területeket gráfelméleti módszerekkel vizsgálták. Eredményeik egy része újszülöttek vizsgálatából ered. Összefüggést találtak a terhesség hossza és az idegrendszer centralizáltsága között. Idős emberek vizsgálata esetén azt figyelték meg, hogy a théta és alfa generátorok a kor előrehaladtával gyengülnek és alhálózatokra esnek szét. Patológiás esetekben az egészséges, szegregált hálózat centralizált lesz és az alhálózatok közötti kapcsolatok mértéke jelentősen csökken. Pusztán gráf elméleti elemzéssel képesek klasszifikálni a patológiás eseteket.

Gulyás Attila: Sokcsatornás agyi adatok elemzésének kérdései és problémái

Az előző előadásokkal szemben itt a kis struktúráktól haladtak a nagyobb szerveződési egységek felé, nevezetesen a jelátvitelben szerepet játszó fehérjék működésén keresztül akarják megérteni az agyi folyamatokat. Arra kíváncsiak, hogy a mikro szinten ható mintázatok hogyan alakítják ki a makro szintet. Itt is lehet gráfelméleti megközelítést használni, de itt más típusú gráfokra van szükség. Itt ugyanis a serkentő és gátló sejtek kölcsönhatásait kell elemezni. A serkentő sejtek hosszú távú kapcsolatot adnak, ezek alakítják a memóriát. A gátló sejtek pedig a modulációt biztosítják. Arra is kíváncsiak, hogy a serkentés/gátlás hogyan biztosít dinamikát, valamint ez a dinamika miként változik az időben. A másik fontos kérdés, hogy miként viselkednek perturbáció hatására?

Káli Szabolcs: Agykérgi idegsejt-hálózatok működésének matematikai modellezése: eredmények és kihívások

Az agyról keveset tudunk, mert egy sokváltozós rendszer, sok heterogén elemmel, melyek jellemzői állapotfüggőek. Ebből következően általános megoldás nincs. A lentről fel modellek nem használhatóak, mert nem lehet az összes paramétert felmérni és a megértést sem segítik elő. (Miről is beszélt Gulyás Attila?). Kénytelenek egyszerűsítéseket bevezetni, ha le akarják írni a folyamatokat. Az egyik ilyen egyszerűsítés, hogy a szinapszis jelfeldolgozó szerepét elhanyagolják. Csak kevés sejt típussal dolgoznak, egyszerűsített kapcsolatot feltételezve. A modellekből hiányzik az idő, mint paraméter. A végső cél természetesen, hogy minél realisztikusabb modellt állítsanak fel.

Remélem kijut a poszt, mielőtt elkezdődik az idei Experience. Ugyanis demo készül nagy erőkkel.

Mint arról már korábban írtam, Betasector a csapatunk legújabb tagja és rögtön aktivizálta magát. Blenderben rittyentett két jelenetet, ami már önmagában is tök jól nézett ki. A feladat elég egyszerűen indult: ezt kell valós időben elkészíteni.

Most, hogy Pythonban is viszonylag otthon vagyok és korábban is használtam a programot tartalmak előállítására, azt gondoltam, nem lesz nehéz a feladat. Ez a túlzott optimizmus. Még ennyi év után is. Ráadásul úgy gondoltam, jó volt ez a Unity, de ideje tovább lépni.

A modellek még gond nélkül bemásztak a demóba. A problémák a kamera animációnál kezdődtek. Eddig fel sem tűnt, hogy a Blender másik koordináta rendszert használ, mint az OpenGL. Persze azért nem tűnt fel, mert az OBJ exporter lehetőségként megadja az "Y up" és "-Z forward" opciókat, ezért az exportált modell az OpenGL környezetben pontosan úgy jelenik meg, mint a szerkesztő programban. A kameránál mindez nem működik.

A pozíció esetén még nincs is gond, két koordinátát kell felcserélni, de a forgatás esetén valami miatt remeg a kép, mintha két forgatási szög között váltakozna. A megoldásra egy Babylon.js fórumban bukkantam. Az itt leírt módszer nem működött, de kellő alapot adott, hogy próbálgatással megtaláljam azt a kombinációt, ami pont ugyan azt az eredményt adja, mint amit a Blender mutatott. Mikor láttam a megoldást, akkor már értettem, miért ezt kell csinálni, de addig nem esett le a tantusz.

Ennyi bevezető után jöjjön a módszer:
import bpy
f = open("/tmp/pos.txt", "w")
camera = bpy.data.objects['Camera.003']
for i in range(bpy.context.scene.frame_end):
        bpy.context.scene.frame_set(i)
        for j in range(4):
                f.write(str(camera.location[j]))
                f.write(" ")
        for j in range(4):
                f.write(str(camera.rotation[j]))
                f.write(" ")
        f.write("\n")
f.close()

A fenti kóddal Blenderből ki tudjuk menteni a kamera pozícióját és forgás szögeit. Természetesen ez még nem megfelelő nekünk. Tegyük fel, minden egyes sor elemeit a pos nevű tömb tárolja. Ebben az esetben a következő kóddal fordíthatjuk őket OpenGL "kompatibilissé":

translate(tr, -pos[0], -pos[2], pos[1]);
rotate(rot, -pos[3] + 1.570796326794897, -pos[5], pos[4]);
matrixMultiply4x4(tr, rot, camera);

Viszont rengeteg időt vesztegettem el a kiderítésével. A másik érdekes kihívás a demó elején három kamera között váltogat a kép, de átmenettel. Ez igazából nem bonyolult, csak én még nem programoztam ilyet. Annyi történt, hogy a jelenetet három kameraállásból textúrába rendereltem, majd a második lépésben, mikor jött a post-processing, a két textúrát mixeltem. Mivel itt a shader mindig két textúrát várt, ezért készült egy nagyon ronda boiler-plate kód, hogy amikor csak egy képet kell mutatni, akkor is van mix, csak 100%-ban a második textúra látszik. Nem szép, de ekkor a sok éjszakázás és gyereksírás között már nagyon nem tudott érdekelni, hogy a kód elegáns legyen.

Az utolsó nap Shamen is meglepett egy stílusos befelyezéssel. Addig a zene egyszerűen csak abbamaradt. Nem volt valami szép, de annyira örültem, hogy nem jártunk úgy, mint Function-ön, hogy nem szóltam miatta. Most pedig még a zene is tökéletes lett!

Szombaton vendégek is jöttek, de csak a gyerkőc érdkelte őket, ezért én észrevétlenül kódolni kezdtem, hogy be tudjam fejezni a demót. Chaten Betasector is bejelentkezett, és az utolsó egy órában adta az instrukciókat, hogyan nézzen ki a demó. Sajnos a második jelenetet így sem tudtam rendesen befejezni. Az alagútas jelenet nagyon lapos lett, ezért Betasector tett bele mintákat és kiadtuk.

Negyedikek lettünk a hét indulóból. Nem lettünk utolsók! A második jelenet hiányosságait majd egy végső változatban utólag kiadjuk.

Az egyik baktérium szekvenálásból van egy nyers genomunk. Mivel végre abból is cikk lesz, fel kell tölteni a szekvenciát az NCBI adatbázisába, hogy a cikkel egy időben az is eljusson a közösséghez.

Annak idején hallottam olyan pletykákat, hogy valaki feltöltötte a Jurassic Park regényben talált szekvenciát, vagy Karácsony közeledtével a Mennyből az angyal szövegét fehérje szekvenciaként. Nem tudom, mennyi igaz belőle, de egyiket sem találtam meg.

Az biztos, hogy mára igen erősen ellenőrzik, hogy mi kerülhet bele az adatbázisokba. Mára már nagyon sok féle adatot fel lehet tölteni. A mi esetünkben a WGS volt a legmegfelelőbb szekció, mert ide nem szükséges kész genomot küldeni. A nyers fasta fájlok fejlécét először formázni kell. Már itt szerepelnie kell az organizmusnak, a törzsnek. Ezután egy letölthető program segítségével (tbl2asn) konvertálni kell. Már ez a program is sok hasznos üzenettel lát el. A dokumentációval ellentétben a figyelmeztetéseket is ki kell javítani, mert a későbbi lépéseknél fog elakadni a feltöltés.

A webes form kitöltése egyszerű, de ha mégis valami hibát vétünk, akkor kapunk róla e-mailt, hogy mit fognak kijavítani. Módosításra ugyanis nincs lehetőség. Ha valamit elírtunk, csak levelezés útján kérhetjük az adminisztrátorokat, hogy változtassák meg.

A manuális munka miatt a feltöltés három napot is igénybe vehet, ha minden jól megy. Ha hibázunk, akkor minden egyes felfedezett hiba további napokkal hosszabbítja a műveletet.

A szekvenciákat is alaposan ellenőrzik. Már csak ezért is kételkedem a fenti két anekdota hitelességében. A mi esetünkben is kaptam egy levelet, ahol kértek, hogy néhány kontigot távolítsak el a feltölteni kívánt szekvenciából, mert azok gorillából, orángutánból és mitokondriumból származnak. Gorilla? Mi folyhatott abban a laborban? Biztos valami nagy buli.

Számtalan neve van: egyensugarú user, Vér Pistike, A szomszéd gyerek. Mind ugyan azt takarja. Van számítógépe, rettenetes mennyiségű önbizalma és egy picivel többet ért a számítástechnikához, mint a körülötte élők. Láthatatlan, de mindenütt ott van. Még soha nem hallottam róla, hogy bárki személyesen találkozott volna egyel is, de internet szerte óva intenek tőle.

Eljött a nagy leleplezés ideje. Most csak Önök, csak itt megismerhetik a mumus igazi arcát. Találkozhatnak a félelmetes buherátorral, a bukott rendszergazdával, a klikkelők szégyenével: Én vagyok Vér Pistike.

Meglepődtek? Miért? Van számítógépem, de csak Chip-magazin szintű tudásom. Segítek a szomszédnak/ismerősnek beállítani a gépét. Nincs sem OKJ-s papírom, se felsőfokú szakirányú végzettségem. Hatalmas önbizalommal vetem bele magam minden olyan feladatba, amit még hivatásos rendszergazdák is visszautasítanak. Az összes bélyeg illik rám. A következtetés tehát egyértelmű: én vagyok, akitől a profi informatikusok óva intenek.

Miért nem tűntem el? Miként vagyok képes a billentyűzet közelében maradni? A válasz egyszerű: szükség van rám. Szükség van a korlátozott tudásomra, amit ingyen bocsátok a rászorulók rendelkezésére. És sajnos a hivatásosok között is van olyan, akinek inkább követ kéne törnie, mint programokat telepítenie.

Nem akarom azt sugallni, hogy minden informatikus ostoba. Rengeteg jó szakember van, de következő történetem szereplőinek egy Vér Pistike volt az utolsó mentsvár...

Az egyik rokonom falun él. Volt egy kis béna számítógépe, amivel valamilyen szinten elboldogult. Skype-on tartottuk a kapcsolatot, de sem a sávszélesség, sem a hardver nem tette egyszerűvé a kommunikációt. Még a YouTube is akadozott.

Ez az ember gondolt egyet és megkérte a munkahelyi rendszergazdáját, hogy állítson össze egy konfigurációt, ami "jó". Mikor kérdeztem, milyen gépet fog venni, csak annyit tudott mondani, hogy "az van ráírva: XXL Gamer Pro". Vagy valami hasonló. Több információt nem sikerült megtudnom.

A régi gépről szeretett volna átmásolni adatokat az újra, de a panelgyári biztonsági őr (akitől kérdezte) megnyugtatták, hogy ez rendkívül bonyolult művelet, ne is próbálkozzon vele. Az operációs rendszer telepítése szintén nagyon bonyolult, mert "fel kell törni a kódot" hozzá. Mintha csak a Hacktion valamelyik epizódját hallanám.

A Skype beszélgetések ezután elmaradtak. (Bizonyára nem sikerült feltörni a kódot.) Telefonon viszont megtudtam, hogy jött a következő probléma: össze kell dugni a csatlakozókat. Mivel ismerősöm mérnök, mondtam neki, hogy próbálja meg ő összedugni. Úgysem tudja rosszul csinálni. Minden csatlakozó csak egy helyre mehet. Ennek ellenére nem merte megpróbálni, hanem rábízta az ex alkoholista nevelt fiára. A fiú, az elbeszélések alapján nem boldogult a feladattal. Felbosszantotta magát és otthagyta a gépet.

Megkértek, hogy telefonon vezényeljem le az összeszerelést. Ezt nem akartam elvállalni, mert én nem látom, hogy ő mit csinál és ő nem érti, hogy én mit akarok.  Azt kértem, hogy először fényképezzék le a gép csatlakozóit és küldjék el nekem. Beszámozom őket, visszaküldöm és az alapján már beszélhetünk.

Vártam, hogy jöjjenek a fotók, de nem jöttek. Végül telefonon felhívtam őket:

- Azért nem küldtem a képeket, mert jött egy hivatásos informatikus. Azt mondja, rossz ez a gép. Nem ad képet.
- Nem biztos, lehet, hogy csak kilazult a videokártya...
- Hú, odaadom az informatikust, beszélj vele...Halló, XY vagyok, informatikus és HelpDeskes. Megnéztem, ez a számítógép hibás.
- Lehet, hogy csak kilazult a videokártya a szállítás során. Meg kellene igazítani...
- Nem lehet, a burkolat eltávolítása garanciavesztéssel jár. Higgye el kérem, hogy ez a számítógép rossz. Kipróbáltam három különböző kábellel, nem ad képet.

Mivel én csak egy Vér Pistike vagyok, meghajoltam a szaktekintély előtt, aki természetesen elkérte a kiszállási díjat, és a fizetséget. Ismerősöm közben átkozódott, hogy csak egy számítógépet szeretett volna, mégis ennyire nehéz szerezni egyet és milyen bonyolult a beüzemelés. Visszaviszi a gépet és talán minden megoldódik.

Mint később kiderült, a gépen van egy alaplapi videokártya is. Két darab monitor kimenet volt, de csak egyet tesztelt le és mivel az nem adott jelet, megállapította, hogy a gép nem működik. Gratulálok neki, innen is.

A következő lépcsőfok a Skype telepítése volt. Annak ellenére, hogy ezt az ismerősöm a korábbi gépen sikeresen megoldotta, most valami miatt nem sikerült neki. Elmondása szerint a Skype letöltéséhez meg kellene adnia az ismerőseinek az e-mail címét, de ő ezt nem akarja. Mi van?

Ez már kezdett bűzleni nekem. Közben jött egy másik informatikus is, aki sikeresen abszolválta a Skype telepítését. De jött a következő probléma: reklámok jelentek meg. Nem lehetett megnézni egyetlen weboldalt sem, mert folyton reklámok jelentek meg.

- Küldtem e-mailt. Olvastad? - kérdeztem tőle.
- Nem, nem tudok belépni a levelezésembe.
- Miért nem tudsz?
- Korábban a Gmail-t mindig a Startlapon találtam, ott írtam be a jelszavamat...
- Mit csináltál? Miért nem a Gmail oldalán?
- Mert nem találom.
- A böngésző címsorába írd be: gmail.com
- Nem tudom, nekem olyan nincs websearch van helyette.
- Mi a fene az a websearch?

Természetesen tőle hiába kérdeztem. A gugli viszont megmondta. A gépre valaki telepített néhány malware-t. Nem állítom, hogy a második informatikus telepítette őket, de az tény, hogy utána akár hányszor hívták, nem vette fel a telefont. Természetesen ő sem ingyen dolgozott.

Ez volt az a pont, hogy már nem bírtam tovább. Elutaztam hozzájuk, úgyis érett már egy találkozó, mert fél éve nem láttuk egymást.

A gépen 13 olyan programot számoltam össze, aminek a nevében shop, clean vagy  password volt. Még csak meg sem próbálták elrejteni valódi szándékukat.

Mivel nem volt kényes adat a gépen, megpróbálkoztam egy rendszer visszaállítással. A művelethez kell a telepítő DVD. Mint kiderült, ez hiányzik. A boltban ugyanis az operációs rendszer nélkül árult géphez az eladó adott tört programot!

Először a naiv megoldással próbálkoztam: A Windows Programok Eltávolítása opciójával. Természetesen nem működött minden progi esetén. Gondoltam, majd akkor a nyers erő módszerével a program könyvtárát fogom törölni. Mivel futó folyamatok voltak, ezért a rendszer nem engedte, hogy letöröljem őket.

Elindítottam az msconfigot, de a rendszerindításnál nem láttam egyetlen gyanús program nevét sem. A CCleaner segítségével kiderült, hogy az ütemezett feladatok között bújnak meg. Ugyan ezzel a programmal szépen eltávolítottam őket onnan, de előtte az elérési út ismeretében felkerestem a könyvtárat és szépen kézzel letöröltem mindent. A CClean eltávolította a hátramaradt Registry bejegyzéseket.

Újraindítás után megnézem, mennyi szemét maradt, majd a lépéseket megismételtem, amíg egyetlen egy sem maradt. A böngészők reklám mentesítéséhez az itt leírtakat használtam.

Csak egy kis kellemetlenség maradt, amit nem sikerült megoldanom: Az aukciós portálokon, online piactereken továbbra is megmaradtak a reklámok. Ez legközelebbre maradt. Linux kellett volna neki, de az igazi gyógyírt elutasította. Fizetségnek akart adni egy bontott csirkét, de nem fogadtam el.

Az intézetünkben van két rendszergazdának látszó ember és egy igazi rendszergazda. Utóbbi, ha épp nem a bögyös titkárnőknek csapja a szelet, akkor igen segítőkész. Ez már a két krampuszáról nem mondható el. Ahogy egy volt kollégám megfogalmazta: olyanok, mint akiken lobotómiát végeztek. Mintha egyiküknek csak a jobb, másiknak a bal agyféltekéjét távolították volna el.

Az egyikük ugyanis "szoftveres", ami annyit jelent, hogy tud nyomtató meghajtót telepíteni. A másikuk "hardveres", ami nem is tudom, mit jelent az ő nyelvükön.

Habár ők is, én is számítógépekkel foglalkozunk, csak ritkán keresztezzük egymás útjait, és ez nagyon is jól van. Viszont történt valami, ami felborította a kényes egyensúlyt.

Azt gondolom, nem árulok el titkot, ha azt mondom, a magyar kutatás számítógép éhségben szenved. Akár kivel beszélek, az első problémája, hogy nem tud számítógépet rendelni. Ez nálunk is így van, de ügyes kutatók megoldották, hogy a semmiből gépek landoljanak nálunk. Annyi gépet nem tudtak szerezni, hogy mindenkinek jusson, ezért a javaslatomra vettek egy Windows szervert is, hogy a régi XP-ket vékony kliensként használjáhassák és az erőforrás igényes műveleteket (pl. e-mail megtekintés) futtassák a szerveren.

Azt is jeleztem, hogy szükség lesz 5 darab licencre. A gépek megérkeztek. Mindenki boldog volt.

Illetve majdnem. Akiktől rendelték a gépeket, hogy mutassák, mennyire értenek hozzá, telepítették a Windowsokat. Valami okból kifolyólag egy licenct használtak ehhez, ezért mikor két gépet kapcsoltak a hálózatra, akkor nem működtek.

A másik ügyes akciójuk az volt, hogy nem annyi memóriával rendelték a gépeket, ahogy kértük tőlük, hanem kevesebbel, rendeltek külön memóriát, majd szétszedték a gépeket és belerakták őket. A garanciának ezzel lőttek.

A rendszergazgáink rárepültek és rögtön telepítették rájuk a Sophos programokat, mert hát az ISO szabvány előírja. Mikor kértük tőlük, hogy állítsák be a szerveren a távoli hozzáférést, a "szoftveres angyfélteke" csak annyit mondot: nem értek hozzá. Nagy barna szemeivel nézett, és mintha ez lenne a legtökéletesebb válasz, amit adhatott volna, megismételte: nem értek hozzá. Már elsőre is világos volt számunka, de valami miatt fontosnak tartotta megismételni.

Elképzeltem, hogy élete első randiján is valami hasonlót alkotott:

- Csókolj meg!

- Nem lehet, nem értek hozzá.

És ülnek tovább a holdfényben.

Végül elvállaltam, mert láttam, hogy különben nem lesz semmi. Utoljára a Windows Server 2003-hoz volt szerencsém. Mikor letölthető volt a nyilvános béta verzió, akkor felraktam a gépemre. Hatalmas magabiztossággal és Stackoverflow-al a hátam mögött nekivágtam, hogy konfiguráljam a rendszert.

A folyamat egyszerűbb volt, mint gondoltam. Bejelentkezés után azonnal egy olyan ablak fogadott, ami arra buzdított, hogy vegyek fel új szolgáltatásokat. A szolgáltatások tematikus rendbe voltak szedve, nem okozott kiválasztani a távoli hozzáférést. Amikor kiválasztottam a nekem kellő elemeket, a rendszer figyelmeztetett, hogy milyen egyéb szolgáltatásokra lesz szükség a hibátlan működéshez.

Az egyedüli kivételt a licence szerver képezte, aminek hiányára egy újraindítás után figyelmeztetett a Windows. A gondok itt kezdődtek. A távoli hozzáféréshez kell egy úgynevezett kliens hozzáférési licence (client access license, CAL). A rendelésnél jeleztem is, hogy erre szükség lesz. Kérdeztem is, hogy merre találom, de mindenki azt állította, hogy ők a gépek közeléből semmit nem vittek el. A dobozokat tényleg nem vitték el.

Neki is álltam átnézni őket, de csak a rendszer visszaállító DVD-ket találtam meg. A CAL hiányzott. A szerver szerint még volt 120 napom, hogy előkeressem a licenceket, ezért a továbbiakban a kliensekre koncentráltam.

A Windows XP esetén egy kis regisztrációs adatbázis turkálásra van szükség, de a nagyobb probléma az volt, hogy nem bírtam kivárni, hogy betöltődjenek. Tucatnyi ikon jelent meg a tálcán, ablakok ugráltak fel jelezve, hogy még egy újabb szükségtelen program van telepítve a gépre. A HP egyik meghajtója ráadásul megjelenített egy ablakot, amit nem lehetett bezárni. A gép előző felhasználója is csak annyit mondott: "Azt a Feladat kezelőből lehet csak eltűntetni."

Megnézem, milyen programok vannak telepítve a gépre: Iphone connectivity ("Kinek van Iphone-ja?" Válasz: senkinek), iTunes ("Ki használt iTunest?" Válasz: "mi az az iTunes?"), Java JDK ("Ki fejlesztett Javaban ezen a gépen?" Válasz: senki), Samsung mobil alkalmazás, Nokia mobil alkalmazás, Google Earth, stb. Csupa olyan program, ami nélkül nem lehet genetikát művelni. Leszedtem, amit tudtam, és láss csodát, a gép használható lett.

A távoli hozzáférés gyönyörűen ment. Már csak a licenceket kell előkeríteni, mielőtt lejár a 120 nap.

A party nagyon jol alakult. Charlie-tól megtudtam egy kisebb demoscene krízis háttértörténetét. Az történt ugyanis, hogy mivel kevés ember foglalkozik a scene.hu weboldallal, ezért Murphy, az egyetlen, aki posztol, be szokott venni olyan híreket is, amelyeknek szinte semmi köze nincs a demoscenéhez. Ami viszont köthető a demoscenéhez, az késve jelenik meg. Emiatt egy csomó kritikát kap.

Egy volt munkatársam is eljött, akinek ez volt az első demoscene rendezvénye, amin részt vett. Jó volt vele is találkozni.

A 256b intrók nagyon tetszettek. Szerintem hatalmas előre lépés, hogy egyre több intrónak van hangja. Azt is jó látni, hogy próbálkoznak alternatív megoldásokkal. Például láttunk egy Processing szkriptet is!

A 4k compó is tartogatott meglepetéseket. Először is az Astroidea release. A csapat ugyanis sok éve nem adott ki semmit. Az indoklast itt hallhatjátok. Szóval így kell megfiatalodni.

A 64k kompó hozta a papírformát, a Conspiracy magasan a mezőny fölött szárnyalt, de azért a Dilemmának sincs oka a panaszra. Agoston 64k-ja pedig semmi újat nem mutatott.

A demók elég változatosak voltak. A Unityben összedobott vacaktól egészen a művészi kompozícióig volt minden. A projektoron nagyon bénán nézett ki a Trabant, mint utólag megtudtam, a VGA-splittereken elveszett a jel egy része. Utolsó elöttiek lettünk, de szerintem volt rosszabb alkotás is a miénknél. A közönség viszont így döntött, nincs mit tenni.

A Blazar erős volt, megérdemelten nyert. A Háromnegyed tíz lett a második. Fültanúja voltam, amint Gargaj és Immortal Rat a demóról beszélt korábban és ettől nagyon nagy elvárásaim voltak. Talán kicsit irreálisak is. Ennek ellenére a stílusa jobban tetszik, mint a Blazarnak. Mu6knak bejött a szöveges mód. Harmadik helyezést ért el. A Hollow Spaces-t pedig nem értem.

A party remek volt, köszönjük a szervezőknek, hogy időt és energiát áldoztak ránk.

Ez a demó készítés kezd olyan lenni, mint egy szappan opera. Emberek beszélnek, kavarnak össze-vissza és keresztbe tesznek egymásnak. Én pedig mindig a fordulat előtt megszakítom a blog írását.

Pénteken az egyetlen jó döntés, amit hoztam, a korai lefekvés volt. Az első előnye, hogy korán fel tudtam kelni. A másik előnye, nem voltam fáradt. Reggel négykor ébredtem és első dolgom az volt, hogy megnézzem, milyen zenét kaptam.

Semmilyet. Az alibi release nem állt olyan szinten, hogy érdemes legyen vele tovább foglalkozni, ezért a korábban említett DVD-ről szedtem két másik zenét és 5 óra alatt beleoperáltam a készülő művekbe. A wildunkra illő zene nem volt, ezért a kezdetleges eszközeimmel levágtam egy zene elejét és végét. A módszer egyetlen előnye, hogy nem lesz néma a prod. Azért többet érdemelt volna, de úgy érzem, azért annyira nem jó, hogy egy következő partira halasszuk.

A demóhoz választott zenével már többet kellett bíbelődni, de cserébe az eredmény is elfogadhatóbb lett. Az időzítés sok időt vett el, de 9 órára készen voltam. Mindent ment a felhőbe, egy pendrivére és már indultam is.

A délelőtt nagyon csendes volt. A helyszín nagyon kultúrált és modern. Elkezdtem beszélgetni az emberekkel. Megtudtam, hogy a Conspiracy minden tagja készített egy demót (persze más csapat néven, hogy maximalizálják a nyerési esélyt). Mu6k csinált valami text mode demót. Talán arra számít, hogy megismételheti a Revision sikerét? Blueghost a partin kezdett el kódolni, de nem sok esélyt látok, hogy befejezi.

Gargajjal az új demótooljáról beszélgettünk. Megtudtam, hogy DirectX-ben van egy debug mód, amivel könnyen ki lehet szűrni az olyan hibákat, amik a hibás állapot beállításból fakadnak. Ilyet OpenGL-ben is el tudnék viselni. Azt is megtudtam, hogy az új eszköz folyamat ábra szerkesztővel programozható. Azon lepődtem meg a legjobban, hogy értem, mit mond. Általában, amikor magas szintű demoscene eszmefuttatásokat hallok, a legtöbb szót nem tudom hova tenni.

Slyspy azt mondta, jövőre már nem fog demókat csinálni, mert öreg. Így hullnak el legjobbjaink a hosszú harc alatt...

Betasector viszont nagyon lelkes. Fejlődik is, ezért úgy döntöttem, jó helyen lesz a csapatunkban.

A Kürt Kft két előadása a deep learningről és az adat visszanyerésről szólt. Meglepő, mire képes a technika. A hatalmas számítógépes kapacitásnak hála ugyanis óriási méretű neurális hálókat tudnak építeni, ami például a képfelismerés terén az emberi teljesítmény határát súrolja. De ha azt nézzük, egy ember mennyi képet tud átnézni egy nap, akkor nyugodtan állíthatjuk, hogy az algoritmusok lepipálnak minket.

Az adatmentős előadás lényege, hogy cégen kívül ne reménykedjünk semmiben, ha adat visszanyerésről van szó és az SSD mindenre jó, csak biztonságos adattárolásra nem. Már csak ezért érdemes volt eljönni. Ja, és a repi pendrivéért. :-)

Annyit beszéltem emberekkel, hogy lemaradtam a zene és grafikai kompókról. Most kezdődik a SIDrip Alliance koncert.

Vajon utolsók, vagy utolsó előttiek leszünk? Milyen lesz a demónk fogadtatása? Megtudhatják a folytatásból!

Eljött a nagy nap. A releaset elkészítettem már kedden és eljuttattam Shamennek, hogy próbáljon meg zenét szerezni rá. Elég kevés időt hagytam rá, de Grass megnyugtatott, hogy "Shamen rövid határidővel is tud dolgozni". Nekem ennyi elég is volt.

Azért csütörtökön már elkezdtem dolgozni a vész forgatókönyvön. Ami annyit jelent, hogy előkotortam a fel nem használt zenéket tartalmazó DVD-t, kiválasztottam a legrövidebb zenét és vadul kalapáltam a billentyűzetet Unityben. Persze nem volt sem textúrám, sem modellem, semmim, de legalább sokáig fenn voltam.

Reggel háromnegyed hatkor kedélyes csevegésnek induló e-mailt írtam, amiben azt tudakoltam Shamentől, hogy jön-e partira és csak úgy mellékesen megkérdeztem, hogy mi hír a zenével. A válaszban kifejtette, hogy egész héten 12 órázik, hétvégén fellépése van, este küldi a zenét.

A melóhelyen az egyetlen pozitívum az volt, hogy sikerült kapcsolatot találni a DNS metiláltság és a MinION készülék nukleotid leolvasása között. De már jöttek, hogy nézzem meg a szekvenciáik minőségét, nem tudják indexelni a BAM fájlokat, nem tudják elindítani az IGV-t, stb. stb.

Hamarabb le is léptem a melóhelyről, úgyis van egy csomó plusz órám. Elkezdtem heggeszteni az alibi release-t, hogy mégsem menjek üres kézzel és fél óránként néztem a leveleimet, hogy megjött-e a zene. Jelen poszt írásának pillanatában még nincs zene. A határidő közeleg. A legjobb az lesz, ha lefekszem, akkor legalább nem úgy fogok kinézni, mint egy zombi.

Egyszerűen nem értem, mások hogyan képesek 1,5 nappal a leadás előtt elkezdeni a demót.

Ismét eltelt egy év és ismét közeleg a Function. Evoke-on kiadták az invitációt, ami azt ígéri, hogy most minden más lesz.

Természetesen ez nem véletlen. Gargaj, aki eddig szervezni szokta, belefáradt az idegtépő munkába és átadta a stafétabotot Pasyéknak. Örömet szerezni az embereknek elég nehéz, főleg a demoscene-n belül, ahol az emberek harsányan adnak hangot véleményüknek.

Az új gárda szemmel láthatóan belead anyait-apait, hogy méltóak legyenek a bizalomra. Egy valami mégsem fog változni: ugyan úgy sereghajtók leszünk.

Már egy ideje készítjük a demót, de nem látom, mi az, ami megfogná a nézőket. Nem találok semmi érdekeset benne. A másik dolog, ami talán nagyképűen fog hangzani, de úgy érzem, kezdjük elérni az ingyenes Unity határait. Nem vitás, hogy rengeteg időt spórolunk a használatával. Az sem kérdéses, hogy sok olyan funkciója van, amit még nem tudok ilyen minőségben implementálni (vagy egyáltalán implementálni). De akad olyan része is, ami sokkal egyszerűbben működik saját kódból.

Például a shaderek. Egy szimpla fehér zajt ráültetni a végső képre nagyon egyszerű OpenGL-ben. Unityben elég macerás. Egy csomó körítést kell hozzáadni, hogy befogadja a keretrendszer. Igaz, utána már könnyű paraméterezni, de míg addig eljutunk...

A másik a részecskék. Nem emlékszem, hogy ennyire körülményes lett volna animálni őket, pedig minden paramétert kódból állítgatok. Még az is lehet, hogy ez a baj :-)

Ami biztosan készül még, az egy wild. Megpróbálkozunk egy vicces, de figyelemfelkeltő videóval. Ennek a fogadtatására nagyon kíváncsi leszek, mert olyan témát feszegetünk, ami vita egy ideje demoscene körökben.

Végezetül annyit mondanék, aki tud, jöjjön el. Mi biztosan ott leszünk.

Nemrég statisztikai számításokkal kellett kisegítenem egy projektet. A probléma az volt, hogy aki eredetileg végezte a számításokat egy warez SPSS-el, elment babázni, a cikk bírálói viszont további összehasonlításokat szerettek volna látni. Így kerültem én a képbe.

SPSS-el nem tudtam szolgálni, de teljesen legális R-el igen. Össze is gyűjtötték nekem az áhított összehasonlításokat én meg írtam egy szkriptet, ami elvégezte a nem kevesebb, mint 150 ezer t-próbát és a hozzá tartozó többszörös teszt-korrekciót. Nagy boldogan átnyújtottam az eredményeket, de nem volt váll veregetés.

A probléma az volt, hogy a kísérlet vezetője már "látta" az eredményt és ezt a statisztika nem támasztotta alá. Először csak arra kértek, hogy hagyjam el a Benjamini-Hochberg korrekciót, hogy több szignifikáns eredmény legyen (hahaha), majd miután így sem lehetett igazolni az elvárásokat, másik tesztet kértek. Sajnos én nem ismerem "Látszik" tesztet, ami pont ugyan azokat az eredményeket hozza ki, amiket elvárnak emberek.

A probléma ugyanis a szórás volt. A kísérletet 3 évben végezték el, három ismétléssel, és az évek között akkora szórás volt, hogy a kontroll és a kezelés átfedett. Ezt mindenki értette és senki sem vitatta. Cikkek alapján viszont elvártak bizonyos trendeket, amik elő is jöttek, ha hunyorítva néztek a grafikonokra. De csak nekik. Nekem valahogy nem megy a hunyorítás. Szerettek volna egy olyan tesztet, ami "nem érzékeny a szórásra". Valószínűleg az én műveletlenségem, hogy nem ismerek ilyet.

Miután itt holtpontra jutottunk, arra kértek, hogy legalább ismételjem meg R-el az SPSS-s manova analízist. Ez egyszerűnek tűnt, de kiderült, hogy sokkal nehezebb, mint gondoltam. Kaptam két Excel táblázatot, egy PowerPoint diát, ahol lépésről lépésre leírták, mit csinált az előző kutató. A menüpontokat R parancsokká változtattam, majd összehasonlítottam az eredményt. Egyes eredmények megegyeztek, de néhány változónál olyan mértékű eltérés volt, hogy még a szórás négyzetek nagyságrendje is különbözött.

Első gondolatom az volt, hogy az SPSS-el rosszul klikkeltek. A második, hogy valami paramétert rosszul állítok be R-ben. Mindkét feltevés hibásnak bizonyult. Pontosabban részben hibásnak.

Az internetet bújva először az vált világossá számomra, hogy a különbség igenis létezik. A szórás négyzetet ugyanis többféle módon is ki lehet számolni, ami kiegyenlítetlen adatoknál egészen más eredményt adhat. Természetesen nekünk egyes esetekben ez volt a helyzet. Ezek alapján nem csoda, hogy a statisztikában kevésbé jártas emberek bűvészkedésnek fogják fel a módszert, hiszen látszólag ugyan azzal a teszttel eltérő eredményeket kaphatunk.

De a statisztika nem bűvészkedés. Ez is ugyan olyan eszköz, mint a labor centrifuga. Ha nem centrifugálsz elég ideig, a felül úszóban lesz a mintád és kiöntöd. Ugyan így, ha rossz statisztikát használsz, nem lesz eredmény. A másik dolog, amit nem szabad elfelejteni, hogy ha rossz bemeneti adatokat használunk, akkor az eredmény is rossz lesz. Egy befertőzött táptalajról senki nem akar baktériumot tisztítani, de két ismétlés alapján már ki merik jelenteni, hogy a különbség szignifikáns.

Talán egy hasonlattal rá tudok világítani a lényegre. Gondoljunk úgy a statisztikára, mint az étkezésre. Mást eszünk vasárnap egy családi ebédnél és mást a moziban. Nyilván lehet pattogatott kukoricát is felszolgálni a rántott hús helyett, de a végeredmény nem lesz ugyan az. Pontosan így van a statisztikában is. Többféle teszt van gyakran ugyan arra a feladatkörre is, de azért, mert mindegyiket csak bizonyos körülmények között érdemes használni.

Ahogy pörköltet sem szokás magában enni, hanem valami körettel, úgy bizonyos statisztikai teszteket is együtt használunk.

Most játszunk egy kicsit. Én leszek a kibic, aki nem érti a táplálkozás lényegét: Minek kell három fogás? Csak tele lesz a gyomrunk tőle. Inkább együnk csak dobos tortát, amikor éhesek leszünk. Mi? Attól nem lehet jóllakni? Biztosan rosszul készítették el. Nem kell villa sem hozzá, mert olvastam, hogy valaki a szájpadlásába szúrt egyet. Inkább kézzel kanyarítok a közös tálról, ha kell. Egyéb tápanyagok bevitele csak bűvészkedés, a szervezet mindent elő tud állítani szénhidrátból.

Ugye milyen fájdalmas hallgatni?

Minden nemzetnek megvan a maga totemállata. A genom programok korában nem meglepő, hogy ezen állatok szekvenálása különösen fontos az adott nemzetnek, így pénzt, energiát nem kímélve végzik a feldolgozást.

A kínaiaknak ott az óriás panda, az amcsiknak a "négyszázas" ló, nekünk magyaroknak pedig a mangalica.

A projektbe viszonylag későn kapcsolódtam be, ezért csak marginális szerepem volt, de ahhoz mindenképp elég volt, hogy a cikkbe kerüljek. Sőt, egyes pillanatokban úgy éreztem én hátráltatom a csoportot.

Először a projekt vezetői között volt egy kisebb vita arról, hogy csináljunk-e további vizsgálatokat, vagy ne. Én úgy láttam, hogy sokan belefáradtak a disznó genom boncolgatásába, ezért ők a mielőbbi publikálást preferálták. Az is gond volt, hogy ketten elhagyták a kutató csoportot és új helyen igyekeztek helyt állni. Végül mindenki beadta a derekát és megkezdődött a cikk írás.

Már tavaly elkészült a kézirat, de a bírálók kifogásoltak rajta több vizsgálatot, ezért a decemberben igyekeztünk a hiányosságokat bepótolni, hogy még az ünnepek előtt vissza tudjuk küldeni azt. Az egyik ilyen kifogás az volt, hogy miért a Samtools-t használtuk a variációk detektálására, miért nem a GATK-t. Szerencsére korábbról volt már tapasztalatom az eszközzel, így enyém lett a megtisztelő feladat, hogy lefuttassam azt.

Szerencsére idő előtt végeztem is vele, így abban a megnyugtató tudatban mentem szabadságra, hogy mindent megtettem a siker érdekében. Azért fél szemmel figyeltem a levelezést, így derült ki, hogy bizony SNP-k vannak, de az indelek valahogy hiányoznak. Természetesen kifelejtettem egy kapcsolót.

Rögtön meg is kaptam a magamét. Jóvá akartam tenni a dolgot, ezért az összes elérhető számítógépen GATK futott. A rokonok vacak internetén egy mini laptoppal gyűrtem a bájtokat, miközben hallgattam, hogy milyen jó nekem, mert távolról is tudok dolgozni.

Szerencsére nem kellett az egész Karácsonyt végig dolgozni és a felállított határidőket is tudtuk tartani. Csakhogy a bírálók újabb problémát találtak...

Ekkor kezdődött egy furcsa ping-pong játszma köztünk és a bírálók között, ahol ők kifogásoltak valamit és rendkívül rövid határidőket szabtak nekünk, mi megcsináltuk, és utána hetekig nem válaszoltak semmit. Ez ismétlődött hónapokon keresztül. Szerzőtársaim már különböző összeesküvés elméleteket gyártottak a gonosz disznó kutatókról, akik direkt hátráltatnak minket, mert nem ismerjük a titkos kézfogást.

Közben az újságnál főszerkesztő váltás is történt és az új ember végül megkegyelmezett nekünk és elfogadta a cikket. Mindenki megkönnyebbülhetett. Hurrá!

Különböző fórumokon rendszeresen felbukkan az algoritmusok GPU-ra történő átírása. Ez alól a bioinformatika sem kivétel. A GPU-t amolyan isteni megváltásnak tekintik minden problémára. Még olyan emberrel is találkoztam, aki azt gondolta, attól, hogy erős videókártyát tesz a gépébe, máris hatalmas teljesítmény növekedést fog tapasztalni. Ezért is merült fel bennem:  tényleg szükség van rá? Egyfelől ott van az igény a gyors eredményekre, másrészt a szűk keresztmetszet sok esetben a lemez műveletek sebessége. Ebben a posztban megpróbálom kideríteni mekkora a GPU alapú bioinformatikai algoritmusok létjogosultsága. Kiválasztottam néhány programot, amelynek ismert a CPUs válatozata és összehasonlítottam őket. Habár nagy GPU rajongó vagyok, igyekszem objektív lenni.

Tesztkörnyezet

A teszteket egy AMD FX-8350 processzort tartalmazó gépen végeztem 32GB memóriával. A videokártya egy GeForce GTX 460 volt 1GB memóriával. A meghajtóprogram verziószáma 319.60. A tesztgépen egy 64bites Slackware 14.1 futott. A Cuda meghajtóprogram a 6.0 verziószámot viselte.

Programok

NVBio: A csomag része az nvBowtie, de más érdekes program is található rajta kívül. A fordítása gond nélkül sikerült a cmake/make párossal. Ellenfele a a bowtie2-2.2.2, szintén forráskódból fordítva, probléma nélkül.

 GPU-Blast: Az NCBI-Blast GPU-val erősített változata. Telepítés előtt szerkeszteni kellett az install szkriptet, mert letölti a CPU-s változatot az NCBI FTP tárhelyéről és a fájlnévben a verziószám elavult volt. A G-Blastn is ide kívánkozik. Érdekes lesz összehasonlítani nem csak a GPU/CPU teljesítmény különbséget, de az egyes implementációs különbségeket is. (Bár a két README fájl gyanúsan sok egyezést mutat.)

A gBlastn fordítása elég nehezen ment. Az install szkript először vagy letölti az 2.2.28 Blast-ot, vagy kéri a forráskód elérési útját, belemásolja a GPU függő kódot, felül ír más fájlokat és megpróbálja fordítani ezt a katyvaszt. Az 1.1 verzió semmilyen módon nem akart lefordulni. Igaz, a 2.2.28 Blast fordítása is csak úgy ment, ha a ncbi_gnutls.c-ből kitöröltem egy sort. Ebből adódóan, ha az install szkript töltötte le a Blastot, akkor az nem fordult le, mert benne volt a fordítást akadályozó sor. Ha én adtam be az elérési utat, akkor nem volt képes belerakni a saját vackait. Már majdnem úgy nézett ki, nem lesz semmi ebből a bejegyzésből, amikor ráakadtam a GitHubon fejlesztett verzióra. Az öröm korainak bizonyult, mert így a fordítás későbbi szakaszán jelentkezett hiba. Végül úgy döntöttem, nem kísérletezem tovább és kihagyom a tesztből.

 cuda-meme: A program a népszerű motivum kereső GPU-s változata. A fordítás itt sem okozott gondot. A CPU megfelelője a leírások alapján a MEME 4.4, de én az egyszerűség kedvéért a gépemre már korábban telepített 4.9.1 verziót használtam (szintén forráskódból és már sikeresen használtam is).

mummergpu: Ismét egy illesztő program, de ez genomi szinten pakolja egybe a szekvenciákat. Ebben az esetben az eredeti program fejlesztői készítették el a GPU-s változatot. Ezért is lepődtem meg, amikor a fordítás során hiányzó fejléc állományokra és linkelési hibákra utaló hibaüzeneteket kaptam. Egy ideig szenvedtem a kóddal, de végül ez a program is kiesett a rostán.

SOAP3: A kínaiak csodafegyvere a bioinformatika frontján. A de novo programjukkal már szenvedtem, ezért semmi jóra nem számítottam az illesztőjükkel kapcsolatban. Szerencsére ezt nem kellett fordítani, mert csak binárisan terjesztik.

Teszt futtatások

A MEME összehasonlításhoz a Doop adatbázis 85067420 klaszterét használtam. A klaszter 3000-es promótereit töltöttem le (All promoters, 3000bp, Download clusters). Hiába fordult le gond nélkül a program, nálam segmentation fault-al elszállt, még alapértelmezett beállításokkal is. Összehasonlításra így nincs mód.

A Bowtie illesztéshez egy C. elegans genom szekvenálást választottam. A genomot innen szedtem. Már az index építése is eltér a CPU és GPU verziókban. A bowtie2-build helyett az nvBWT program állítja elő azt. Sajnos a folyamat itt el is akadt, mert minden indítás alkalmával más történt. Először úgy tűnt végtelen cikusba került a program, mert fájokat nem hozott létre, de folyamatosan írt a konzolra. Második indításra segmentation fault-ot adott. Nem álltam neki hibát keresni.

Minden reményem a SOAP3-ban volt. A leírás szerint 3GB videomemória kell neki, ennek ellenére belevágtam. Fordítani nem kellett, mert csak binárisan terjesztik a programot. Itt is az index készítésénél akadt el a teszt, mert hiányzott neki a libcudart.3.so.

Összegzés

Bevallom, nagyon meglepett, hogy egyetlen programot sem tudtam használni. Való igaz, hogy sok ponton elbukhat egy Linuxos program telepítése, de ne feledjük, hogy a CPU változatot sikeresen tudtam fordítani és a kész programot használni ezen a rendszeren. Személy szerint azt gondolom, hogy a GPU verziós programok nem érik el kódinőségben azt a szintet, amit a CPU-s változat. A fejlesztők valahogy összerakják a rendszert, ami a saját gépükön elfut és írnak belőle egy cikket, majd nem fejlesztik tovább azt. Ez alól látszólag a gBlastn kivételt képez, mert a GitHub szerint rendszeresen érkeznek javítások a kódbázishoz. Talán a jövőben újra megpróbálkozom a telepítésével, de aki használni akarja ezeket a programokat, inkább támaszkodjon a CPU-ra. Az eredmény biztosabb.