Megtörtént amire nem számítottam: Apple gépet használok. Minden úgy kezdődött, hogy az Amiga Klubban kiosztottak 3 leselejtezett PPC-s Mac-et. Amolyan aki kapja-marja alapon. Mivel én nem nagyon kedvelem az almás gépeket, nem tülekedtem értük. El is meséltem Grassnak, aki először nyugodtan, majd egyre feldúltabb állapotban nekem esett:

- Te önzö állat! Szerinted másnak nem kellene egy Mac?

Igaza volt, tényleg nem jutott eszembe, hogy másnak is szüksége lehet ilyen masinára. Eltelt majd egy év, és ismét felajánottak nekem egy MDD-t. Tanulva a korábbi esetből, azonnal elfogadtam.

Ami miatt Amigás körökben népszerű a géptípus, az a MorphOS nevű operációs rendszernek köszönhető. El is határoztam, hogy Grassnak feltelepítem a MacOSX 10.5-t és a MorphOS 3.1-t. Az egyetlen elérhető dokumentáció alapján el is kezdtem a műveletet. Az almás rendszert feltelepítettem, de boot partícónak 60 helyett 64MB-t adtam, mert a doksi későbbi része is ennyit említ.

Először elkövettem azt a hibát, hogy a partíciók típusát beállítottam "Mac OS extended (Journaled)"-re. Ez azt okozta, hogy később a MorphOS több tucat partíciót látott, és mindegyiket érvénytelennek tekintette. Mikor nem használtam a Journaled formát, már nem volt ilyen gondom.

Az OSX telepítése ettől a ponttól kezdve nem érdemel említést, leszámítva, hogy miután újra indult, legnagyobb meglepetésemre maga a ház kezdett el zenélni. Mivel éjjel végeztem a telepítést, rendesen meg is ijedtem.

A második lépés a MorphOS telepítése volt. Az oprendszer automatikusan felismeri a partíciókat és csatolja is azokat, miután felállt a rendszer a CD-ről. Tehát a doksi nem említi, de le kell csatolni őket, ismét felcsatolni, az ott leírt paramétereket beállítva, és csak ezek után tudjuk formázni a partíciókat. A többi lépés megegyezik az ott leírtakkal.

Az operációs rendszer választás bekapcsolás után az Alt billentyű lenyomására jön elő. Ha pedig optikai meghajtóról akarunk bootolni, akkor a c-t kell lenyomni.

Be kell vallanom, elfogult vagyok. Elfogult vagyok a tudománnyal szemben. Ha meg akarják sérteni, akkor igyekszem a védelmére kelni. Komolyan gondolom, hogy a megismerés jelenleg legjobb módja a tudományos gondolkodás. Ennek egyik pillére a megismételhetőség.

A megismételhetőség egy igen sarkallatos pontja a vizsgálatoknak, hiszen egyrészt új vizsgálatok melegágya, másrészt a régi ismeretek megerősítése.

Munkám során azt a feladatot kaptam, hogy ismételjem meg ennek a cikknek az elemzését. A cikk röviden arról szól, hogy kifejlesztett a Stanford egyetem egy kísérletes és egy számítógépes módszert, hogy meghatározzák a HLA genotípusokat. A szekvenciák egy része elérhető az SRA-n, így nekem csak a számítógépes módszerrel kellett dolgoznom.

A readeket Blast-al illesztették, majd szűrték. Az illesztés és szűrés viszont nekem teljesen más eredményt hozott. Feltételeztem, hogy a szűréssel rontottam el valamit, de szűrés nélkül sem kaptam meg azokat a találatoka, amelyek a cikkben közölt eredményekre vezetnek. Adva van a válasz, hogy a Blast futtatás a hibás. Naívan írtam az egyik szerzőnek, hogy szeretném kérni a Blast program paramétereit. Mikor nem kaptam választ, írtam a következőnek. Így írtam a leveleket, egyiket a másik után, amíg el nem fogytak a kontaktok. Mikor már mindenkinek küldtem levelet, de sehonnan nem jött válasz (pedig korábban az egyik szerző pár napja levelezett is egy munkatársammal), akkor lépett a főnököm. Neki már válaszoltak. Közölték, hogy a Blast paramétereket nem adják oda! Azok ugyanis az ő intellektuális termékeik.

Az még hagyján, hogy nekem nem válaszolnak, hiszen ki vagyok én? Nincs a nevemben CEO, BMW, KGB, stb.. De hogy nyíltam szabotálják egy vizsgálat megismétlését, az már nagyon nem járja. Ezek után miért gondoljam, hogy a módszerük jó? Azért mert ők a Stanford? Ez nekem kevés.

Elképzelem, hogy Mendeltől megkérdezik:

- Hogyan kapta ezeket az eredményeket a borsóval?

- Megmondhatnám, de akkor meg kell, hogy öljelek.

Ezek után nem lenne genetika, nem lenne Watson-Crick és nem lenne nyomorult Stanford hülye paraméterekkel.

A programozásnál nem elég a nyelvi finomságokat ismerni. A jó programozónak eszközöket is ismerni kell, amelyek meggyorsítják a munkafolyamatait. Alapvetően az én munkámat el tudom látni egyetlen vim szövegszerkesztővel, de mikor felvettek jelenlegi munkahelyre - ahol a programozók hatalmas multinacionális cégeknél dolgoztak korábban - bizony a vim már nem volt elég. (A java egyébként sem az a nyelv, amin olyan egyszerű pusztán egy szövegszerkesztővel fejleszteni. )

Szerencsére a nagyobb tapasztalattal rendelkező kollégák beüzemelték ezeket a rendszereket, és nekem nem kellett mást csinálni, csupán használnom azokat. Az idők során újabb eszközök jelentek meg, azokat integrálták, megoldották, hogy a sok inkombatibilis eszköz valami módon együtt tudjon dolgozni.

De történt, hogy új gépet kaptam, ráadásul tesztelnem kellett egy olyan gyorsan iramban fejlesztett alkalmazást, hogy elkerülhetetlenné vált, hogy ne nekem kelljen fordítani az egész rendszert. De ehhez be kellett üzemelni például a Mavent. Gondoltam ez jó alap lesz, hogy megismerjem kicsit jobban ezt az eszközt, ezért saját magam kezdtem el beállítani a gépemen.

Ahogy lenni szokott, problémába ütköztem. Megkértem a legközelebbi programozót, segítsen, de azt válaszolta, ő nem ért a Mavenhez, ez az eszköz rossz, bezzeg régen milyen jól ment a munka, amikor még XY eszköz volt a maga primitívségében. Nem volt mit tenni, szólni kellett a Maven Guru-nak, aki az egész rendszert összerakta, hogy segítsen nekem. A Maven Guru kiíratott velem egy csomó logot, elméleteket gyártott. Mondtam neki, hogy az egyes komponensek letöltésével van probléma, mert ezt mondja a hibaüzenet. De ő továbbra is üzeneteket dekódoltatott velem, kulcsokat hasonlítottunk össze, meg minden-féle feketemágiát űztünk, talán csak csirkét nem álldoztunk. Végül kiderült, hogy van egy weboldalunk, ahol egyetlen linkre kattintással kapásból a legfrissebb verziót tudjuk fordítani.

Végül nem állítottam be semmit, hanem ezt a módszert használtam. De sajnos utólért a végzet. A fejlesztést átvariálták, de a klikkelős módszert nem. Mondanom sem kell, hogy ez is a nyári szabadságok közepén ért. Mivel senki nem fogja helyettem megcsinálni, ideje, hogy kézbe vegyem a dolgot. Félretettem minden munkát, és módszeresen végignéztem, miért nem találja a Maven a titkosító kulcsot. Öt perc alatt megtaláltam, hol írtam el a fájlnevet, ami senkinek nem tűnt fel, majd elkezdtem fordítani.

Mivel a Maven előszeretettel tölt le hihetetlen mennyiségű jar állományt az internet különböző zugaiból, míg megírtam ezt a kis bejegyzést, addigra le is fordult a program.

Amikor először hallottam, hogyan készült a Moove című Fresh!Mindworkz produkció, nagyon elcsodálkoztam. A felvételt ugyanis Aha kézzel processzálta. Minden egyes képkockánál megjelölte, hol van táncos keze. Már pontosan nem emlékszem, mennyi klikkelést kellett végrehajtania, de nekem már az egy százaléka is sok lett volna.

Felvetődik a kérdés, mit csináljanak azok a demócsapatok, ahol nincsenek ilyen elhivatott tagok, csak lusta kóderek? A válasz egyszerű: bízzuk ezt a munkát is számítógépre.

Az OpenCV egy olyan API, ami rengeteg hasznos módszerrel igyekszik segíteni a képfeldolgozást. Nem kell nekünk megvalósítani a bonyolult algoritmusokat, hanem csak használni azokat. Miként használhatjuk ezt a demosceneben? Csak nézzünk meg néhány ASD demót! Ők már 2006 óta használják olyan produkciókban, mint az Evolution of vision vagy a Happiness is around the bend.

Mielőtt elkezdeném tárgyalni, mit is tudunk kezdeni ezzel az API-val, kicsit részletezem saját tapasztalataim alapján, hogy mit is várhatunk el a számítógépes látástól. Közhely, hogy a számítógép csak pixel információkat dolgoz fel, míg az ember formákat, de nagyon könnyű erről megfeledkezni. Ha nem akarunk kedvenc videónk feldolgozása alatt kiguvadó szemmel meredni a monitorra, miközben azt üvöltjük: Miért nem látod azt az intenzitás változást! Akkor érdemes megjegyezni a következőket:

- Ami az ember számára egyforma színűnek tűnik, az a gép számára lehet eltérő. Például készítettem egy felvételt homogén fal előtt, de az árnyékom halványan rávetült a falra, a program már másik színnek látta.

- Ha csökkentjük programunk érzékenységét, olyan helyek is egyformává válhatnak, amiket mi szemmel meg tudunk különböztetni. Például a Livin' in a box című demónk készítése közben az egyik jelenet felvételénél a távolban volt egy fa, aminek az árnyéka olyan sötét volt a program számára, mint a ruhám. Ez zajként jelentkezett.

- A színeket a számítógép több komponensben látja (pl. RGB vagy HSL), ami a feldolgozásnál meglepetéseket okozhat. Pl. egy alkalommal zöld korongokat akartam detektálni, minden mást kiszűrni. Azt gondoltam, elég a zöld csatornával játszanom, de a ruhámon egy sárga minta folyton bezavart. Egyébként sok algoritmus az OpenCV-ben csak szürke árnyalatos képpel működik.

- A kamera fényérzékenysége eltér szemünkétől. Ez szintén trivialitás, de ha arra kényszerülünk, hogy mobiltelefon felvételt dolgozzunk fel, ne lepődjünk meg semmin.

- A video kódolás hibákat okozhat a feldolgozásban. Ez sem rakéta-tudomány, de az OpenCV nem minden telepítés esetén olvas minden fájl formátumot. Esetenként konvertálnunk kell, ami megváltoztathatja a feldolgozandó pixeleket.

Most, hogy túlvagyunk az "én szóltam" részen, lássuk, mit képes olvasni az OpenCV? Alapvetően a következő képformátumokat támogatja: BMP, JPG, PNG, TIFF. A videoformátumok már rendszerfüggőek. Windows alatt mindent olvasni tudunk, amihez van Video for Windows kodek. Linux alatt a dokumentáció az ffmpeget említi, de Ubuntu és Fedora esetén olvassa a GStreamer támogatta videókat. Mac alatt be kell érni QuickTime-al.

Ha valós idejű képfeldolgozásra adjuk a fejünket, akkor használhatunk webkamerákat. Jó eséllyel nem lesz gondunk vele, ha a rendszer tudja kezelni. Sok tapasztalatom nincs ez ügyben, a laptopom beépített webkameráját kezeli mindenféle hókuszpókusz nélkül.

Az OpenCV tartalmaz még egy kicsi, lebutított keresztplatformos grafikai felületet, amit HighGUI néven szoktak emlegetni. A lényege, hogy platformfüggetlen módon egyszerű felületeket fejleszthetünk. Az eszközkészlete elég szegényes, csak ablakokat, képeket és csúszkákat hozhatunk létre.

Ennyi bevezető után lássunk egy kis kódot, ami alig csinál valamit, de ismerkedni jó lesz:

#include <opencv/cv.h>
#include <opencv/highgui.h>
#include <stdio.h>

void processImage(IplImage *raw){
   cvSmooth(raw, raw, CV_GAUSSIAN, 17, 0, 0, 0);
}

int main(){
   CvCapture *capture;
   IplImage *frame;
   IplImage *proc;
   int key;

   capture = cvCaptureFromCAM(CV_CAP_ANY);
   cvNamedWindow("win", CV_WINDOW_AUTOSIZE);

   while(1){
      frame = cvQueryFrame(capture);
      processImage(frame);
      cvShowImage("win", frame);
      if(cvWaitKey(10) != -1) break;
   }

   cvReleaseCapture(&capture);
   cvDestroyWindow("win");
}

A kód a következő módon fordítható GNU/Linux rendszeren:

gcc simplecapture.c `pkg-config --libs opencv`

Végezetül a könnyed műfajok kedvelőinek itt van néhány tipp, miként rejtőzködjünk el a kamerák arcfelismerő algoritmusai elől divatos, de extravagáns frizurákban: CVDazzle

Nemegyszer előfordult, hogy biológusok, orvosok tanácsot kértek tőle, hogyan végezzenek el egy bizonyos elemzést. Régebben elmondtam a program nevét, felsoroltam a paramétereket, amikor váratlanul megkérdezték

- Tudni fogom, hova kell klikkelni?

- Persze. Sehova. Ez egy parancssoros program.

Ekkor derül ki, hogy a kérdező valami Windowsos programot szeretne, ahol csak klikkel egyet és megkapja az eredményt. Mindezt lehetőleg egy átlagon aluli teljesítményt nyújtó számítógépen. Ilyenkor természetesen nem tudok érdemben segíteni, legfeljebb felajánlom, hogy majd lefuttatom én a programokat egy GNU/Linuxos gépen.

Később már visszakérdeztem, milyen számítógépeken akarnak bioinformatikát művelni, amivel a félreértéseket elkerülhettem. Azért felmerült bennem, mégis milyen lehetőségek vannak Windowson? Ebben a posztban kipróbálok néhányat ellenséges operációs rendszeren.

Tesztkörnyezet

A tesztgép egy AMD 4400-as 2,2GHz-en, 4GB memóriával. Az operációs rendszer 64 bites Windows 7, amire a cikk idején az összes automatikus frissítés felment. A webes megoldásokkal nem foglalkoztam, csak olyan programok próbaverzióit használtam, amit bárki le tud tölteni. (Mint az látszani fog a posztból, ez nem is mindig olyan egyszerű)

A tesztfeladat elég egyszerű: Egy Ion Torrent szekvenciát kell a humán referenciához illeszteni, megkeresni a variációkat, és összevetni egy már ismert eredménnyel. A szekvencia nyilvánosan elérhető, de sajnos regisztrálni kell az oldalra. A szekvenáláshoz egy AmpliSeq kitet használtak, ami több, daganatos megbetegedésekben szerepet játszó genetikai polimorfizmusok környékére szűkíti a szekvenálást. Az oldalon a szekvencia mellett megtaláljuk a szekvencia célpontokat (BED állomány), valamint egy másik analízis eredményét (VCF).

Geneious 5.6.4

A Geneious 14 napos próbaverziója könnyen letölthető. Még valódi e-mailt sem kell megadni. A .gz kiterjesztésű fájlokat elkezdte betölteni, de egy idő után rájött, hogy nem tudja, mit is tartalmaz, ezért nem ment tovább. A kibontás után, importálás közben automatikusan meghatározza a fájl típusát. A referencia fájlokkal könnyedén boldogult, még arra is rákérdezett, hogy a sok kijelölt FASTA állományt egybe kezelje-e.

Az illesztésnél már adódtak problémák. A teljes humán referencia futtatásához 8Gb-ra van szükség, holott minden egyes kromoszóma külön-külön beleférne 4Gb-ba. Az alapértelmezett memória, amit a program fel tud használni 1Gb, amit nekünk kell manuálisan megnövelni. (De ehhez adminisztrátori módban kell futtatni a programot.)

A BED állományt is szépen beolvasta, de előtte ki kellett jelölni, hogy melyik referenciát kívánjuk annotálni. Ez általánosságban jellemző a programra, hogy először mindig az adatokat kell kijelölni, és csak utána kell kiválasztani a funkciót.

Az illesztés megtekintésekor ellenben speciális menüket kapunk, hogy a további vizsgálatokat elvégezhessük itt. A nukleotid polimorfizmusok keresését a kissé megtévesztő Annotate & Predict menüpont alatt találjuk. Az eredményeket pedig CSV állományba menthetjük. Nem VCF, de azért megteszi. Az viszont már gond, hogy exportáláskor az összes annotáció egyszerre kerül mentésre, tehát a variációk és az amplifikált pozíciók ugyan abban a fájlban lesznek. Az illesztés is exportálható SAM formátumban.

Mivel a VCF-t nem tudtam importálni, ezért nem tudtam összevetni sem, amit kaptam a teszt adatokkal. Az amplifikált régióban található variációkat is csak szemmel tudtam azonosítani, ráadásul az exportálás során összemossa az annotációkat. Ugyanakkor pozitívum, hogy a táblázat elemei között klikkelve az illesztés megfelelő pozíciójára ugrik, ami segít.

Összességében ez a program elég sok manuális munkát ad. Nehézkes, az egyes funkciók eléréséhez felugró ablakok környezetfüggő menüiben kell matatni. Továbbra is az a véleményem, hogy klasszikus feladatokhoz remekül használható, de újgenerációs szekvenálások esetén inkább kerüljük el.

CLC Genomics Workbench 5.5 beta 2

Úgy döntöttem, mivel nemsokára kijön az új verzió, ezért a bétával fogom a teszteket lefuttatni. Kérnek regisztrációt, de semmi valódi adatot nem kell megadni.

A referencia importálása kromoszómánként történt, és a program kromoszómánként is kezeli őket. Nincs olyan lehetőségünk, egy egybe fogjuk őket, mint a Geneious esetén. Természetesen egy könyvtárba szervezhetjük őket, de az mégsem ugyan az. A FASTA állományok importálásával nem volt semmi gond, leszámítva, hogy sokáig tartott.

A readeket szekvenáló gép alapján lehet importálni, az Ion Torrent támogatott, nem volt vele probléma. Az annotációval annál inkább. Sem BED, sem VCF állományokat nem tudtam betölteni, de a GFF támogatott.

Illesztésnél megadhatunk több referencia fájlt, és nem akarja egyben betölteni az összeset a memóriába. A beállítások egyszerűek egy parancssoros programhoz képest. Bár most nem használtam, lehetőség van egyszerűbb kötegelésre is, ha több szekvenciát is szeretnénk hasonló beállításokkal futtatni. Nem túl bonyolult, de adott esetben hasznos is lehet. A kész illesztést elmenthetjük SAM/BAM formátumban.

A variációk felderítésére két módszer is van. Az egyik a nemrég debütált Probabilistic Variant Detection, míg a másik, a hagyományos alapokra (a referenciától eltérő readek arányán alapul) épülő Quality-based Variant Detection. Az Ion Torrentre jellemző homopolimer hibát képesek az algoritmusok figyelembe venni. Az eredmény mindkét esetben lehet annotációként a referenciára rakni, vagy külön táblázatban nézegetni. A Geneiousnál megszokott klikkeléssel nem lehet a referencia megfelelő pontjára ugrani, azt kézzel kell kimásolni (a vágólapot sem használhatjuk a koordináták másolására). A táblázatot CSV formátumban is elmenthetjük.

Az eredményt annotációs trackként is megjeleníthetjük. Ez, bár nem egy szofisztikált eszköz, de használhatjuk a variációk összehasonlítására. Mivel VCF-t nem tudtam betölteni, ezért a kétféle variáció detektáló algoritmus eredményét hasonlítottam össze a képen. Az elemzésben több segítséget nem kapunk.

A CLC népszerű újgenerációs szekvenálások feldolgozásában. Rengeteg eszközt ad a kutatók kezébe, ha kis számú adattal kell szöszmötölni. A számítógép mellé persze nem árt egy hagyományos jegyzetfüzet, mert a vágólap használata nélkül kénytelenek vagyunk kézzel lejegyezni apró információkat.

GeneSpring NGS 12.1

A GeneSpring, mikor még aktívan használtam, egy chip elemző program volt csupán. Azóta ők is nyitottak az NGS felé. A próbaverziót regisztráció után lehet letölteni, ahol bármilyen e-mail címet megadhatunk. Mivel már korábbról volt hozzáférésem, ezért könnyedén le is tudtam tölteni a próbaverziót, amit 20 napig használhatunk.

Sajnos a licencet már nem sikerült szereznem hozzá, mert 6 évvel ezelőtt letöltöttem egy másik próbaverziót, ezzel eljátszottam minden életemet. Később sikerült aktualizálni a licencet, így már nyugodtan kipróbálhattam a programot.

Az első kellemes meglepetés az annotációk automatikus frissítése volt. Az első indítás után kiválaszthattuk az általunk vizsgált lény referenciáit és beállíthatjuk, hogy mit töltsön le. A szokásos referencia importálást ezért kihagytam és a frissítést választottam. Kiválasztottam a dbSNP-t is, ami jelentősen megnövelte a letöltési időt. Nagyjából 4 órán át tartott a RefSeq, a genom és a 135-ös dbSNP importálása, amit én soknak tartok.

Fontos kihangsúlyozni, hogy a Genesprint az Agilent terméke, ami azért fontos, mert a szokásos DNS chipek mellett más laboratóriumi kiteket is forgalmaznak. Ezen kitek kiértékeléséhez szükséges egyéb adatok a programba be vannak építve. Például a SureSelect targetáló termékcsalád genomi célpontjai.

A program nem tartalmaz short read import funkciót. Egyáltalán semmit nem tudunk kezdeni short readjeinkkel ezzel a programmal. Az illesztés ki-ki oldja meg maga saját eszközével. A BAM fájlt már be lehet tölteni és lehet keresni nukleotid polimorfizmusokat.

Sajnos nem találtam meg a módját, hogyan lehetne VCF fájlokat beimportálni, pedig ha sikerült volna, akkor a Differential SNP Analysis segítségével izgalmas összehasonlításokat lehetett volna csinálni. De ha BED vagy CSV formátumban vannak adataink, akkor mindez nem jelent problémát.

Egyetlen komoly problémám volt csak a programmal, hogy rettenetesen lassú volt. Minden egyes művelet esetén valamit nagyon töltött. Még ha csak a látható ablakokat akartam kimenteni a program beépített képlopó módszerével, akkor is elkezdett tölteni, frissíteni. Ha kicsit átméreteztem az ablakokat, akkor is elkezdett újrarajzolni mindent, amihez töltött valamit a merevlemezről. Az a gyanúm, hogy semmilyen indexelést nem végez a program, ezért minden újrarajzolás idején elkezdi betölteni a referenciát és az annotációt, hogy megkeresse a kirajzolandó adatokat.

A program sokat tud, de nehéz eligazodni rajta. A súgó pedig leírja, hogy miként kell egy analízist elvégezni, de a hibakezelés teljes egészében hiányzik. Néhányszor előfordult, hogy a súgó szerint követtem a lépéseket, mégis kaptam egy hibaüzenetet, amivel nem tudtam mit kezdeni.

Az előző két programhoz képest itt nem műveleteket végezhetünk, hanem elemzéseket. Nincs illesztés, nincs primer tervezés, van viszont R integráció, SNP feldolgozás és különböző összehasonlítások. Statisztikát kapunk mindenről, amiről csak akarunk.

Avadis NGS 1.3.1

Már a poszt megírása után tudtam meg, hogy létezik még egy program, ami érdemes lehet, hogy belevegyem az összehasonlításba. Ez a program nem más, mint az Avadis. A felhasználói felület és a program logikája teljesen olyan, mint a GeneSpringnek. Nem tudom, mi a kapcsolat a két cég között, de az biztos, hogy azonos kódbázisból dolgoznak.

A két program azonban teljesen más felhasználási területre készült. Amit hiányoltam a GeneSpringből, azt itt megkapom. Először is, lehet közönséges FASTQ fájlokat betölteni, akár tömörített formában is. A readek minőségéről kapunk statisztikát, mintha a FastQC-t használnánk. A BED állományt is minden gond nélkül be tudtam tölteni.

A readek illesztéséhez a BWA-ból ismert Burrows-Wheeler alapú illesztőt használ. Arról, hogy mennyire jó, talán majd egy másik bejegyzésben írok. Az illesztés minőségéről szintén képet kaphatunk néhány statisztika segítségével. Ez szintén hasznos funkció, és nem is láttuk másik alkalmazásban.

Szemben a GeneSpringgel, itt már tudunk VCF állományokat is importálni, valamint többféle variáció felderítő algoritmussal is kísérletezhetünk. A hagyományos SNP keresésen kívül felderíthetjük a strukturális változásokat, az SNP Effect Analysis segítségével pedig meghatározhatjuk, az adott variációnak milyen hatásai lehetnek. A különböző variációkat össze is hasonlíthatjuk, ezzel ez volt tesztünk egyetlen programja, ami mindegyik feladatot maradéktalanul végrehajtotta.

Lasergene Genomics Suite

A DNAStar programcsomagot régen használtam, méghozzá azt a verziót, amit minden magyar kutatóintézet használt. Egy PhD-s, aki fiatal korában egy külföldi cracker csapat tagja volt, feltörte a programot, és attól a pillanattól kezdve mindenhol azt használták. Már megjelent több újabb változata is a programnak, de itthon mindenki csak ezt a régi, de "ingyenes" verziót használta, mivel a benne található funkciók bőven kielégítették egy átlagos kutató igényeit.

Az új divathullámnak megfelelően van NGS alapokon nyugvó programcsomagjuk is, amit egyszerű halandó nem tölthet le, csak, ha regisztrál. A regisztrációt én nagyon komolyan szoktam venni, ezért olyan nevet szoktam választani, amiről lerí, hogy semmi köze a valóságoz. Az űrlap a végén arról tudósít, hogy egy munkanapon belül megkapom a letöltéshez szükséges információkat.

Sajnos ez nem igaz. Valóban kapok e-mailt. de arról, hogy válaszoljak olyan kérdésekre, mint például mennyi pénze van a cégnek, mi a kutatási területünk, stb. Itt kicsit felhúztam magam, ezért megírtam, hogy nem vagyok hajlandó egyetlen kérdésre sem válaszolni, amíg meg nem kapom a próbaverziót, valamint nem értem, hogy ez a bonyolult rendszer miért szolgálja az én érdekeimet. Válaszoltak, ahol leírták, hogy meg akarják védeni a programjukat az olyanoktól, mint én, akik 30 napig ingyen használják azt a napi munkájukhoz, de utána nem fizetnek. Megírtam, hogy ehhez a blogbejegyzéshez kellett volna a program, de mivel ez egy kicsi, magyar nyelvű blog, senkinek nem fog hiányozni a DNAStar terméke.

Partek

Ez az a program, amiről a poszt írásának idején értesültem először. Egy Google keresés adta ki eredményül. A próbaverzió megszerzése kisebb hadműveletet igényel. Először is egy webes űrlapot kell kitölteni, ahol a Hotmailt. GMailt és társait nem adhatjuk meg e-mail címként, csak céges e-mailt. Mivel még működik a régi egyetemi címem, azt adtam oda nekik. Kaptam egy levelet a következő munkanapon, ahol egy lmtools.exe letöltésére és futtatására szólítottak fel. Ez a gépről egy csomó adatot összeszed, becsomagolja, majd vissza kell küldeni a válasz e-mailben. Csak ezután kapjuk meg a licencet. Én egy hét után sem kaptam tőlük semmit, pedig megpróbáltam egy másik regisztrációt is új néven.

Összefoglalás

Még mindig nehéz dolga van annak, aki Windows alatt szeretne bioinformatikát művelni. Az Avadis NGS kivételével mindig akadt egy-két lépés, amikor el kellett volna hagyni a programot, hogy a feladatot máshol oldjuk meg. De sajnos ezek a programok nem arra vannak kihegyezve, hogy kooperáljanak más alkalmazásokkal, hanem ellenkezőleg, igyekeznek elszigetelni a felhasználót a külső világtól. Kevés az import/export funkció (bár meg kell jegyezni, hogy mind a Geneious, mind a CLC bővíthető pluginekkel). Érdekes kirándulás volt ez a klikkelős világban, de ha el akarom végezni a munkámat, akkor jobban megbízom az összehekkelt Bash scriptjeimben és a parancssoros programokban. De ha valakinek mégis egy összetett alkalmazás kell, akkor az Avadis megfelelő választás lehet.

Ez a demónk egy kísérletből született. Egy ideje nagyon foglalkoztat a házi motion capture gondolata, ezért elkezdtem tanulni az OpenCV-t (amiről hamarosan írok egy poszt-sorozatot). Úgy láttam, ez nagyon jó demo-alap lenne, Grass-al ezért elkezdtük tervezni a demót.

A másik lökést az adta, hogy tavaly megemlítettem egy AmiCon-on is, mivel foglalkozom, és Spenot felajánlotta, hogy kölcsönadja a Kinectjét, hogy azzal is kísérletezzem. Decemberben került sor az átadásra, egy hétig játszhattam vele. Gyorsan lementettem néhány videót, amit majd remélhetőleg fel fogok tudni használni a demóban.

Az egyetlen probléma az volt, hogy megközelítőleg 2GB méretűek voltak a mélységi információk. Ez még a legengedékenyebb compó-szabályzatnak sem felelnek meg. Szükség volt valami tömörítésre. Egy viszonylag egyszerű megközelítést alkalmaztam. Ahol a következő képkockában eltérés volt az előzőhöz képest, ott letároltam a koordinátát és a megváltozott értéket. Ezzel 7 és 11 MB méretűek lettek a fájlok. Úgy gondoltam további trükközésre nincs szükség.

Januárban videókat készítettem egy mobiltelefonnal, amit egy Amigás winchester beépítő kerettel rászereltem egy fotóállványra. A telefon videorögzítő képességével nem voltam megelégedve, mert gyakran minden figyelmeztetés nélkül leállt a felvétel. A másik probléma a színhűséggel volt. A fakó színek miatt a videofájlok feldolgozása volt problémás. Közben folyamatosan fejlesztettem egy kontúr detektáló programot, ami OpenCV-n alapult.

Februárban Grass nekem adta az egyik fényképezőgépét, ami már könnyedén ráült a fotóállványra, a videofelvevő képességével is elégedett lehettem. Egyedül az alacsony akkuidő hátráltatott. A kontúrokat már jól felismerte a program, el is készültek a demó felvételei. Annyit azért meg kell jegyeznem, hogy igyekeztem megkönnyíteni a program dolgát, amennyire csak lehetett, ezért fekete szabadidő ruhában, kesztyűben ugráltam a kamera előtt. Ez télen még nem volt akkora probléma (bár a hó a hátamon megolvadt), tavasszal viszont izzasztó volt.

Úgy emlékszem, ez idő tájt született meg a demo címe is, amit Grass talált ki, egy régi együttes után, akiknek hasonló nevük volt, legismertebb daluk pedig megegyezett az együttes nevével.

Márciusban a felvételekkel párhuzamosan írtam a demót, Grass pedig ellátott különböző tartalmakkal és ötletekkel a színekre vonatkozóan. Mivel elég messze lakunk egymástól, és nem volt demo kompatibilis laptopom, a gépemet megosztottam VNC-vel, így igaz, hang nélkül, de Grass is láthatta, hogyan alakul a produkció. Néhány esetben még az is ment, hogy az ötleteit azon nyomban megvalósítottam.

Néhány jelenetet leszámítva elkészült Revisionig, ahol mindenki tudja, mi történt. Parti után egy ideig nem csináltam semmit, majd ismét nekiláttam foltozni a hiányzó részeket.

Egyetlen nagyon komoly hiányossága volt/van a demónak, mégpedig a trianguláció pontatlansága. A demó ugyanis csak a körvonalat tölti be, majd felosztja háromszögekre és textúrázza a poligont. Sajnos egyes esetekben ez a lépés megszakad és üres lyukak maradnak. Rengeteg időt töltöttem, hogy megoldást találjak. Megpróbáltam egy automatikus módszerrel kiszedni a kereszteződött szakaszokat, de ezzel gyakran kivágtam a kontúr nagy részét, így inkább letettem róla. Próbáltam másik algoritmust készíteni, de azzal egy csomó időt elbíbelődtem, és nem készült el. A határidő viszont kérlelhetetlenül közeledett. Végül megpróbáltam csalni. A lyukakat valami gyors módszerrel befoltozom, de ezek általában konvexé alakították a poligonokat, ami ugyancsak rosszul nézett ki. A végén semmit sem változtattam meg.

A demóban igyekeztem OpenGL 4.1-t használni, mert így sok effektet shaderben tudtam programozni. Sokat segített, hogy nem kell újrafordítani a demót, csak a shader forrásában turkálva állíthatom a paramétereket. Ez főleg akkor volt a segítségemre, amikor a tömegközlekedésen kellett tuningolni a demón. Más racionális oka nem volt a választásnak. Egyébként is úgy szeretek demót írni, hogy valami újat tanuljak az elkészítése közben.

A produkciót mindenki megtekintheti a poue.net-en, YouTube-n. A forráskód elérhető GitHub-on. Ez utóbbinak az az előnye is megvan, hogy Gargaj elkészítette a Windowsos válozatát is. Ha lesz felvétel az élő közvetítésről róla, azt is belinkelem.

Charlie röviden összefoglalta a Newtech Meetupon az újgenerációs Amigák helyzetét. Az előadás kicsit spontánra sikeredett, de ez nem okozott gondot senkinek. Az előadás után megnézhettek az érdeklődők egy Efikát és egy MacBook-ot, amin MorphOS fut. Megjegyzem, ez utóbbi Magyarország egyetlen laptopja, amin újgenerációs Amiga fut.

Természetesen voltak más érdekes előadások is. Kiemelném az újra felhasználható elemekből álló műanyag préselő szerszámokat, illetve egy beágyazott rendszerek fejlesztésébe betekintést engedő előadást.

Volt egy közösségi oldalakat összefogó közösségi oldal is, aminek a létjogosultságát nem sikerült megértenem. (Bár ebben az is közrejátszhatott, hogy elég ellenségesen viseltetek a kismillió közösségi oldal irán, ami inkább elszigeteli az információáramlást, mint ténylegesen segítené, de erről egy másik posztban)

Jók ezek az összejövetelek, mert adnak egy kis kitekintést, hogy mások épp mivel próbálkoznak, milyen problémákat oldanak meg. Nekik magunkak kell kitalálni a lépéseket, mert - ahogy a mottóm is mondja - senki nem oldja meg helyettük.

A tengeren túli partikkal az a baj, még ha közvetítik is élőben az adást, azt is egy lehetetlen időpontban lehet csak megnézni. Így volt ez az @Partyval is, amit kénytelen voltam hajnali 3-kor megtekinteni. Természetesen a compók késve kezdődtek, így a napfelkeltét a számítógép előtt néztem végig. Közven azon gondolkodtam, miért nem keltem fel később, hiszen a zenei és grafikai alkotásokra nem vagyok kíváncsi.

Ennek ellenére a vetítő compó igen érdekes volt. Régi írásvetítőt kellett használni, hogy demószerű effekteket érjenek el. Meglepő, hogy mire képesek a találékony elmék...

Engem persze a mi demónk érdekelt leginkább. Reggel 6 körül már le is adták. A szervezők a nagy partykhoz hasonlóan felvételről adták le a demónkat, ami nem lett volna baj, ha nem csúszik el a kép és a hang szinkronizációja. A másik probléma az volt, hogy a tesszelációs shaderrel készült hátterek irtó bénán néztek ki. Olyan volt, mintha a shader futása megszakadt volna félúton. A vége előtt pedig egyszerűen megszakadt.

Összességében egy katasztrófa volt. Az eredményeket még nem tudom, de nem számítok sok jóra.

Frissítés:

A pouet.net kiírás szerint úgy tűnik, mintha megnyertük volna. Ha ez így van, el sem merem képzelni, milyen lehetett a többi induló.

A Magyar Bioinformatikai Társaság éves gyűlésén érdekes beszélgetésnek voltam tanúja. Az utánpótlás nevelésről folytatott eszmecsere során a jelenlévők elmesélték, hogy az országban hol, milyen formában oktatnak bioinformatikát.

A Pázmány Péter Katolikus Egyetemen például molekuláris bionika néven találkozhatunk vele. Habár az oldalon olvasható leírás nem kapcsolódik szorosan ahhoz az ismeretanyaghoz, amit itt a blogomban bemutatok, nem árt tudni, hogy az oktatók között ott van Falus András és Pongor Sándor, akik a magyar bioinformatika meghatározó alakjai.

A Budapest Műszaki és Gazdaságtudományi Egyetemen is van ilyen tantárgy. Itt matematikai oldalról ismerhetik meg a hallgatók ezt a tudományt. A tematikát olvasva erősen statisztikai, adatbányászati központú oktatás folyik itt.

Szegeden is tanítanak bioinformatikát, ami a legközelebb van ahhoz, amit én is művelek. Ezen kívül még máshol is tanítanak ilyen-olyan néven bioinformatikát, de ennek a posztnak a célja nem az, hogy ezeket mind felsoroljam.

Tehát látunk három megközelítést, amelyek igen kis mértékben fednek át. A beszélgetés is azt a konklúziót vonta le, hogy magának a bioinformatikának nincs egységes arculata. Ha azt mondom, ornitológus, akkor mindenkinek egy olyan ember fog beugrani, aki füttyről ismeri meg a madarat. Ha botanikusról beszélek, akkor olyan valakit képzelünk el, aki hason csúszik a kvadrátban és gyökérgümő szőr alapján azonosítja a gazokat.

De ki a bioinformatikus? Egy matematikus, aki a szekvenciát L hosszúságú A halmaznak látja, ami {A,T,G,C} elemeket tartalmaz? Vagy egy olyan kutató, aki egész nap egy vegyszerszagú laborban dolgozik, és végül futtat egy Blastot az eredményekből?

Én nem tudom a választ, de a beszélgetés rávilágított arra, hogy mások sem. Szerencsére az akadémikusok mindenre tudnak megoldást, de ha megoldást sem tudnak, akkor szerveznek egy konferenciát. Ezért októberben lesz egy konferencia, ahol a spektrum összes tagja képviseltetni fogja magát és mindenki egy-egy előadással bemutatja, hogy miért is tartja magát bioinformatikusnak.

Ma tartották a Bioinformatika Magyarországon című előadás sorozatot, ami rövid betekintést nyújtott a hazai kutatóműhelyek elért eredményeibe. A megjelenő kis számú érdeklődő a Tudományos Akadémián a fehérjék vizsgálatától az elméleti matematikáig minden témakörben hallhatott érdekességeket.

Röviden, a teljesség igénye nélkül a következő részleteket emelném ki:

Patthy László azzal az érdekes megfigyeléssel kezdte, hogy csökken a bioinformatikába vetett hit. Míg korábban azt gondolták, a bioinformatika lesz a megoldás mindenre, addig olyan problémákat hagyott ez a tudományterület megoldatlanul, mint a génannotáció. A génannotáció pedig minden elemzés alapja. A MisPred egy fehérje térszerkezeti tudásbázison alapuló megoldást nyújt erre a problémára.

Simon István előadásában az volt számomra a legérdekesebb, hogy Ő már akkor bioinformatikával foglalkozott, amikor - kis túlzással élve - ez a tudományág még nem is létezett. A programozás mellett azt is tudja, hogyan kell megfogni a pipettát, mert a kísérletes munkából is kivette a részét. Legjobban az érzékeltette, mennyire megelőzte korát, hogy az általuk megalkotott térszerkezet prediktáló eljárás hátránya nem a pontosság volt, hanem az, hogy a kísérletes módszerek gyorsabban adtak eredményt!

Barta Endre két mezőgazdaságilag fontos haszonállat, a szarvasmarha és a mangalica genomjának bioinformatikai elemzéséről beszélt. Az ember számára fontos géntulajdonságok meghatározásán túl a fajtaspecifikus variációk felderítése és a szabályozó régiókban fellelhető nukleotid polimorfizmusok azonosítása a céljuk. Egyetlen dolog csalt csak mosolyt az arcomra: a szarvasmarhában azonosított géneket egér modellben tesztelik. A döntés labortechnikai szempontból logikus, de csak egy pillanatra képzeljünk el egy "jól tejelő egeret".

Harrach Balázs előadása a PhD hallgatók áldozatos munkájáról szólt. A csoport ugyanis vírusokat, vírus törzseket vizsgál, de gazdaállatokkal együtt. Minden egyes gazdaállat vizsgálatához szükség volt olyan PhD hallgatókra, akik megfelelő "hobby"-val rendelkeztek a minták begyűjtéséhez. Például így segített a barlangász a denevér minták begyűjtésével, vagy az ornitológus az avevirusok osztályozásánál. A lelkesedés olyan szintű a csapatban, hogy még a két hetes döglött tengerimalacot is felkutatták, csak, hogy mintát izoláljanak belőle.

Simon Péter előadásából nem sokat értettem. Egy elméleti matematikai megközelítést használtak járványterjedés szimulálására. A terjedést gráfokon keresztül írták le.

Miklós István szintén matematikai oldalról mutatta be a bioinformatikát, de igyekezett azt a hallgatóságnak is emészthetővé tenni. A biológiában előforduló folyamatok között vannak NP nehéz feladatok, ahol a számítási igény elképzelhetetlenül nagy. Az ilyen folyamatokat leíró modellek esetén azt is bizonyítani kell, hogy a feladat megoldható-e.

Elérkeztünk kedvenc programcsomagunkat bemutató sorozatunk záró részéhez. Azokból a programokból válogatok, amelyek valamilyen kapcsolatban vannak a grafikus megjelenítéssel.

Az Emboss egyik nagyszerű tulajdonsága, hogy a grafikus tartalmat megjelenítheti képernyőn, de elmentheti PostScript, PNG állományokba is, ami egy cikk esetén lehet hasznos. Csak mellékesen jegyzem meg, hogy a legtöbb klikkelős, grafikus program mellőzi teljesen ezt a lehetőséget, és a kutató kénytelen képernyőképeket készíteni és valamilyen grafikus programmal levágni a szükségtelen részeket. De lássuk inkább a programokat.

abiview: A Sanger szekvenálás eredménye sok esetben nem egy kész szekvencia, hanem egy intenzitás görbe, ami azt mondja meg nekünk, hogy az érzékelő milyen nukleotidot detektál az adott pozícióban. A program segítségével megjeleníthetjük ezt. A másik hasznos funkciója, hogy képes kiolvasni a szekvencia sorrendet és elmenteni fájlba.

prettyplot: Többszörös illesztést jeleníthetünk meg vele. Mint minden Emboss program, ez is hihetetlen mennyiségű fájlformátumot ismer. Sajnos az interaktivitás terén nem jeleskedik, ezért ne számítsunk rá, hogy oda-vissza ugrálunk a különböző pozíciók között.

plotcon: A prettyplothoz hasonlóan itt is a többszörös illesztéseket vehetjók górcső alá. A különbség, hogy a program megpróbálja a konzerválódott szakaszokat kiemelni. A konzervált szakaszok méretét a wordsize paraméterrel állíthatjuk be.

plotorf: A lehetséges nyitott leolvasási kereteket képes megjeleníteni. Érdemes még megemlíteni a showorf programot, mely a plotorf szöveg alapú testvére. A -start és -stop opciókkal a leolvasási keretet határoló kodonokat adhatjuk meg. Amennyiben nem akarjuk mind a hat leolvasási keretet megjeleníteni, parancssori kapcsolókkal korlátozhatjuk, mit jelenítsen meg a program.

dotmatcher: Két szekvencia illesztésének vizsgálatakor lehet hasznos, ha a hasonló szekvencia-részletek vizuálisan is megfigyelhetőek. A program az összehasonlítandó szekvenciákat a függőleges és vízszintes tengelyen reprezentálja, míg a hasonló szakaszokhoz egy pontot rajzol. Ha a két szekvencia megegyezik, egyetlen vonalat látunk, ami a bal alsó sarokból a jobb felsőbe tart.

Tisztelt Bíróság!

Az a bug úgy volt, hogy nem is volt bug. Tetszik tudni, én írtam egy demót Revisionre, amit nem is adtak le. Azt mondták, hogy lehet 1024x768 módot támogatni, ha akarok, és én akartam. Ugyanis tisztelt bíróság, nekem nincs ilyen széles izém, mi az? képernyőm. És én csak 4:3 oldalaránnyal tudok dolgozni, és ezért lett ez a felbontás.

Aztán szóltak a compó előtt, hogy nem megy ki teljes képernyőre a demó, pedig olyan felbontása volt, amire aztatat mondták, hogy lehet. De amikor láttam a compógépen a felbontást, annak az oldalaránya nem volt 4:3, hanem inkább 16:9. És az Ubuntu 12.04 ezen a felbontáson kiteszi az ablakot teljes képernyőre, de a Unity eszköztár ott marad. De azután otthon csak annyit csináltam, hogy felvettem egy 16:9-es felbontást, és a Unity eszköztár eltűnt, amikor kiment teljes képernyőre a demó. Tehát kérem szépen, a kódban nem volt bug, csak nem volt felvéve a megfelelő felbontás. És akár mit dönt a bíróság, ez a demó le fog menni @Partyn, mert ott jó fejek az emberek.

A Kerekerdő közepén a törpék Linuxot használnak a számítógépeiken. Sokáig használják azokat, így gyakran lemaradnak a legújabb trendekről és újdonságokról. Jól elvannak a kis parancssorukkal, lassan forgó merevlemezükkel és a szaporodó pixelhibákkal együtt.

Történt azután, hogy hogy-nem, egy program tesztelése közepette rájöttek, hogy bizony 1-2 GB gyakran nem elég az összes adat feldolgozására. Tanakodtak is sokat a kerek erdő közepén, a munka meg csak állt, mert bizony a régi laptopok nem átallottak Out of memory kivételeket dobni.

A nagy varázsló ekkor úgy döntött, hogy a bevételekből ideje áldozni szorgos kis törpéire, hogy még vidámabban húzzák az igát. Kaptak is szép új laptopokat. Csodájára járt Kerekerdő apraja és nagyja. Csak nézték a villogó ledeket, símogatták a tapipadot, ami szinte teljesen beleolvadt a burkolatba. Keresték a pöcökegeret, de ezeken az új masinákon már nem volt ilyesmi.

Nosza, a törpék rögtön elkezdték telepíteni az Ubuntut, annak is 11.10-es változatát. Közben tovább nyomkodták az érdekes és rejtélyes gombokat. A telepítés végeztével viszont furcsa jelenség zavarta meg kis törpéink életét. A tapipad nem ment! Az egérmutató ott virított a 16:9-es képernyő közepén és nem mozdult.

Ejj lett ám szitkozódás, hogy csak úgy zengett Kerekerdő! Bizony, nem voltak restek összehozni az Ubuntu fejleszőinek édes szülőit minden féle egzotikus állattal, majd ékes szóval le is festették a légyottokat.

A legbölcsbb törpe, aki máskor a káromkodásban is élen jár, most csak csendben mosolygott. Várta mikor száll el a harag köde a fiatalabb törpék szeméről, majd megsúgta nekik a megoldást. Rendszergazdakén el kell távolítani a psmouse kernel modult, majd újra be kell tölteni. Néztek nagyot a törpék, majd szó nélkül másztak be a parancsértelmezőbe és kapcsolgatták a psmouse kernelmodult, mintha mi sem lenne természetesebb. Láss csodát, a tapipad megjavult. Ismét működtek a laptopok.

Csak később vették észre, hogy ezeken a fránya új laptopokon ki lehet kapcsolni a tapipadot egy jelölés nélküli gombbal. A nagy játékban bizonyára lenyomták anélkül, hogy tudatosodott volna bennük, mit is csinálnak. De végül sikerült egy igazán bonyolult megoldással rendbehozni.

Az idei Benjamin Franklin díjas Heng Li. Röviden tekintsük át, miért is érdemelte meg ezt a díjat.

Az újgenerációs szekvenáló gépek kimenetét a legtöbb esetben egy referencia genomhoz kell illeszteni. Az illesztés kimenete egy SAM vagy BAM fájl. Amennyiben ezeket a fájlokat fel akarjuk dolgozni, az első program, ami kezünk ügyébe kerül, a Samtools. A programcsomag fejlesztése a nevéhez kapcsolódik. A Samtools jelentőségét mi sem mutatja jobban, hogy a Torrent Suite 1.5 részét képező SNP detektáló algoritmus ezen alapul.

A másik híres alkalmazása a BWA, egy rendkívül jól megírt illesztőprogram. A BWA-val sokat dolgoztam, összehasonlító tesztekben ezt tekintettük alapnak, amelyhez viszonyítva igyekeztünk jobb eredményeket elérni. (Talán annyit elárulhatok, hogy elég kevés sikerrel.) A memória igénye alacsony, sebessége pedig bőven kárpótol mindenért. Összehasonlító tesztekben még nem láttam olyat, ahol lecsúszott volna a dobogóról.

Chip-Seq kísérletek kiértékelése esetén találkozhatunk a MAQ programmal. Személy eddig még nem használtam, ezért nem is szeretnék róla sok szót ejteni.

Aki ezek után azt gondolja, hogy Heng Li csupán egy ügyes programozó, téved. A rizs genom véglegesítésében is dolgozott, csak úgy, mint a selyemlepke szekvenálásában. Ha valakinek még ez sem lenne elég, a csirke variációs térképének feltérképezésében is közreműködött.

Publikációs listája itt tekinthető meg. Innen is gratulálunk neki a díjhoz.

Találkoztam az Alpha Raid csapattal, akik elárulták, mi a játékuk titka, amitől teljes képernyőn sem fagy ki. Ez pedig az SDL. Kicsit csalódott voltam, de ez van. Az embernek mindig magának kell kitalálnia a megoldásokat. Gargaj összeismertetett az @Party egyik szervezőjével. Megígértem, hogy adok be oda is valamit, ha már voltak olyan kedvesek, hogy megengedik, hogy távolról is lehet nevezni. Akkor még nem is sejtettem, milyen könnyen fogom tudni tartani az ígéretemet, de erről később.

Meghallgattam egy szemináriumot, hogyan kell sikeres zenéket írni. Az egy órás előadás tanúságát most megosztom az olvasóimmal: Nézd meg, mit szeretnek az emberek és másold le belőle azt, amit szeretnek. Ezért már érdemes volt idejönni.

Egy másik szeminárium hekkelhető routerekről szólt. Annyira hekkelhető, hogy még kábelt is adnak, hogy konzolról beloggoljon az ember a készülékre. A cross-compilinghoz teljes virtuális gép képet adnak, a router kernele pedig fel tudja csatolni a fejlesztőgép vinyóját. Ez már valami!

A procedurális grafika nagyon tetszett. Már rég nem azok az idők járnak, hogy asztrakt formákat rajzolnak ki. A cél immár a realizmus megragadása. A 64k-k is igen jól sikerültek, ezek közül is kettő volt, ami nagyon megragadott. Az egyik a technológiai tudásával. Egy kis sziget növényvilágát renderelték le. A másik pedig egy játékszobába enged betekintést, ahol épp nem tartózkodnak élőlények. Mindig is rajongtam a történettel rendelkező alkotásokért, ezért ez nagyon tetszett.

A régi gépek 4k-i nem voltak olyan érdekesek, de itt is érezhető volt, hogy újdonságokra törekedtek. Az Amiga demók is jók voltak. Kedvencem, az Elud megelégelte, hogy nem képesek nyerni és beleadtak apait-anyait produkciójukba. Volt minden, amit szeret a közönség: sárkány, dubstep, a gép fizikai korlátainak feszegetése. Nem tudom, mit csinálnak, ha mégsem nyernek :-) Természetesen akadtak kevésbé kifinomult művek is. Az egyik példának okáért felolvasott egy receptet.

A PC demókat hagytam a végére, mert ebben érdekelt vagyok. Legalábbis úgy gondoltam, hogy érdekelt vagyok, mert rögtön úgy kezdték a kompót, hogy három csapattól elnézést kértek, amiért nem fogják bemutatni a produkciójukat. Köztük voltunk. Pasy szerint azért, mert túl sok PC demó van. A jó ebben, hogy van időm megfixálni a rossz részeket. Majd beadom @Partyra, ahol nem fenyeget az a veszély, hogy olyan sok demó lesz. Mivel azért piszkál, hogy a mi nevezésünket szórták ki, elmondom, hogy a nagy nevű, sokak által várt demó mit tartalmazott: Fülsiketítő színusz hullámot, fehérzajt, recsegést és ropogást. Én befogtam a fülemet, de szegény Mu6k, aki az első sorban ült, majdnem megsüketült. És még hosszú is volt. Mindez állítólag valami polgárpukkasztó poén akart lenni. Ez van.

A tegnapi nap elég sűrű volt. Reggel zuhanyzás után meghallgattam két szemináriumot. Az első a demók post-processingjéről szólt. Én még eddig egyetlen egyszer sem használtam semmilyen ehhez hasonló módszert, ezért érdeklődéssel figyeltem. Ha feltöltik az előadásról készült videót, ide is belinkelem.

A második szeminárium már nem volt olyan hasznos, mint képzeltem. Egy új szoftverese szintetizátort mutattak be, ami tartalmazott egy szerkesztőt, egy saját programnyelvet, JIT fordítót, talán még szintetizátort is. Elég bonyolultnak nézett ki, hogy használhatatlan legyen a csapatunknak. Hibáktól sem volt mentes.

Kaptam a szervezőktől egy üzenetet, hogy nem jó a demónk, ezért félve kerestem fel őket, hogy megtudjam, mi lehet a baj. Kiderült, hogy nem Ubuntu 11.10, hanem béta 12 alatt akarják lejátszani a demót, mert a 11.10-ben gond van a hálókártya támogatással. Béta állapotú Ubuntun nem teszteltem, ahol az volt a gond, hogy teljes képernyő esetén a Unity eszköztára ott maradt, rontva az élvezhetőséget. Mivel nem tudom újrafordítani laptopon, maradt az a verzió, hogy lemegy ablakos módban. Nem szabad elfelejtenem, hogy a demokódot át kell írni gtk-3.0-ra és meg kell nézni ezt a teljes képernyős bugot.

A tracked music tetszett. Voltak jó és kevésbé jó alkotások, de nem akartam kimenekülni a teremből. Népes mezőny indult a fotó kategóriában. Nem volt velük semmi gond. Az animációk elég gyengére sikeredtek, ezen a Los Angeles Lamersel közös produkciónk sem segített. Executable musicból viszont rengeteg volt. A végére teljesen összefolytak az alkotások. Sehol nem éreztem kiugró teljesítményt. Hallgattam az egymás után jövő muzsikákat és egyik sem fogott meg.

A webes introk ellenben jók voltak. Mellettem Archee az összeset leszólta, de én továbbra is úgy érzem, hogy az Adinpsz igazán kitett magáért. Lehet, hogy nekünk is meg kellett volna próbálkozni beadni valamit ebben a kategóriában? Talán jövőre.

A régi gépek szerelmesei ezen a napon tobzódhattak leginkább. Ekkor mutatták be a zenéket, grafikákat és demókat a 8 bites platformokra. Izgalmas volt látni, mivel próbálkoztak az emberek. Számomra érthetetlen módon egy Amigás release is bekerült közéjük, megcsillantva, mire is számítsunk másnap.

Romeo Knight koncertje késéssel indult, és a nagy hangerő ellenére is igazi fergeteges hangulatot hozott. Ezt sok esetben csukott szemmel hallgattam. Nem a zene élvezetét kívántam fokozni, csupán tartalékoltam erőimet a compókra, amelyek éjjel kettőkor értek véget. Mellettem Mu6k fiatalos lendületében azt hitte, kibírja ébren, de átaludta a compókat. Csak a végükre ébredt fel, a hangos tapsolásra. Ennyit utazni, hogy utána otthon, YouTube-ról kelljen megnézni az alkotásokat...

A release nem lett kész teljesen. Maradtak benne bugok, egy jelenetet meg úgy kínlódtam ki. Annyira fáradt voltam, hogy néztem a béna jelenetet és nevettem. Később úgy döntöttem, ezt nem érdemes beadni, mert annyira rossz. Partira ellenben nem érdemes release nélkül menni.

Korán lefeküdtem, másnap reggel pedig indultunk. A közlekedés szokás szerint a legrosszabb formáját hozta. A sínen közlekedő eszközöket gumikerekes járművekkel pótolták, amiket eltérítettek egy baleset miatt. Nem volt számottevő a késés. A gyűjtőponton találkoztam Mu6k-al. Fél óra múlva ott volt Archee is.

Az út hozzávetőlegesen 11 óra volt. Nem történt semmi érdekes, leszámítva, hogy mikor mélyen bent jártunk Németországban, kiszúrtam egy másik magyar rendszámú autót. Előzéskor gondolkodtam, mivel lehetne üdvözölni honfitársunkat, amikor megláttam a vezetőt. Kínai volt. A hosszú út arra is jó volt, hogy meghányjam-vessem a demónk ügyét. Beadjam, nem törődve semmivel, vagy tartsam vissza, hogy javítgassam?

A parti körül már sok scener gyűlt össze. A nagy kivetítőn a Vakondok 2 ment. Úgy vettem észre kedvező fogadtatásban részesült. Az angol fordítás is jól sikerült.

Vezeték nélküli hálózat nem volt, ezért egy kábelen osztoztunk sokan. Vetésforgó-szerű rendszerben feltöltöttük a releaseket. Végül a képernyőn keresztül farkasszemet néztem a becsomagolt demóval, és úgy döntöttem, egye fene, adjuk le.

Nem hagyott nyugodni a hiba, ezért a vektorizáló programot szedtem darabokra. Viszonylag egyszerűen működik: veszi az első képkockát, majd az összes többi képből kivonja azt. Gyakorlatilag a mozgó elemek kontúrját szedem ki. A kontúrokat alakítom át később poligonokká, és itt volt a hiba.

Ha csak a kontúrokat rajzolom körbe, és a kontúr vonala megszakad, a poligon visszakanyarodik a hézag mentén. Ezért tapasztaltam azt, hogy megváltozik a poligon orientációja. Eltávolítottam a vektorizálóból a kontúr keresést és helyettesítettem egy olyan kóddal, ami fehérre meszeli a kép azon területeit, ahol eltérés található a videó első képkockájához képest. A fehér maszatot gond nélkül olyan poligonná tudtam alakítani, amit már fel tudott bontani háromszögekre a demó.

Újabb jelenetet is adtam a demóhoz, szintén geometriai shaderrel. Nagyon tetszik, hogy egyre több kódot pakolhatok át shaderekbe, mert a demó fordítása nélkül tudom változtatni a jelenetek paramétereit.

Sajnos ennek a videós módszernek van egy nagy hátránya is. A jeleneteket nehéz úgy összefűzni, hogy ne legyen feltűnő az illesztés helye. Ezt úgy igyekeztem megoldani, hogy az összes részt azonos kameraállásból, azonos fényviszonyok mellett vettem fel. Ennek ellenére mégsem sikerült minden problémát kiküszöbölni. Az első az operatőr árnyéka volt, ami szintén mozgott és a szintén poligonként bekerült a végső állományba. Eltűntetni viszonylag egyszerű volt: koordináta alapján elkülönítettem és töröltem őket. A második problémát viszont nem ilyen egyszerű megoldani. A kamera ugyanis tele állásnál igen jelentősen torzít, tehát az alak mozgás közben megnő. Ha jó lesz az idő, talán meg tudom ismételni a felvételeket, de nagy a valószínűsége, hogy nem lesz rá idő.

Az időzítések problémáját megoldottam, a trianguláció viszont kifogott rajtam. Először arra gyanakodtam, hogy a metódusokban követtem el valami hibát, ezért kiszedtem őket, és egy külön programban teszteltem a működésüket. A várakozásoknak megfelelően hiba nélkül teljesítettek.

A figyelmem ekkor a poligonok felé fordult, ahol meg is találtam a hibát. A vektorizáló kód elkezdi felépíteni a poligont, majd a felénél megfordítja a körüljárási irányt. Emlékeztek? Az ear clipping csak akkor működik, ha a körüljárási irány nem változik.

A vektorizáló program egy olyan API-n alapul, amit nem tudok megváltoztatni. Nem ismerek olyan geometriai eljárást, hogy a poligon pontjait körüljárási irány szerint sorba rendezhetem, ha valaki mégis beírná a kommentek közé, nem biztos, hogy lenne elég időm, hogy implementáljam. A lehetőségeket figyelembe véve, Grassal úgy döntöttünk, kihagyjuk a produkcióból és csak körvonalak fognak szerepelni.

Az idő vészesen fogy, még vannak hiányzó jelenetek, de továbbra is úgy látom, még be tudjuk fejezni.

Közben a Los Angeles Lamers csapatot is kisegítjük, mert ők nem tudják kivinni a produkciójukat Revision-re, ezért koprodukcióban készül egy wild is. Zenét és egy logót kaptak tőlünk. Ha találok valami elfekvő kódot, amiből valami érdekeset lehet generálni, elküldöm nekik.

A hétvégén elkészítettem még egy jelenethez a videókat, este pedig elő VNC adásban megmutattam Grassnak, hol is tartunk. Rögtön előjött egy csomó hiba:

1. A C#-os algoritmus C-re ültetve nem úgy működik, ahogy kellene. Valahol bugos a kód.
2. Ubuntu alatt lassabb a képfrissítés, amitől egyes jelenetek szinkronizációja elcsúszott.

Ellenben kijavítottam két korábbi hibát. Még sok jelenetet kell megfelelő szintre hozni. Mint mindig, most is az idővel van a probléma, ezért a céges laptopot is befogtam a munkára, hogy munkába menet és jövet a tömegközlekedésen tudjak kódolni. A gond csupán annyi, hogy a laptop nem ismeri a legújabb OpenGL szabványt, de a trianguláció hibáját lehet rajta keresni.

A szinkronizáció viszonylag egyszerűen megoldhato, attól nem félek, de lesz-e elég idő minden hiba kijavítására?

Trianguláció

A demóban több két dimenziós poligon lesz látható. Mivel szeretnénk rá textúrákat rakni OpenGL alatt, kénytelenek vagyunk felbontani őket háromszögekre. Minden sokszöget fel lehet bontani háromszögekre a matematikusok szerint, de a sokszög bonyuloltságától függően több algoritmust használhatunk. Mit jelent ez a gyakorlatban? A sokszöget alkotó csúcspontokat megadhatjuk véletlenszerűen, vagy szisztematikusan. A sokszög élei metszhetik egymást, tartalmazhatnak lyukakat, sőt a lyukak újabb lyukakat.

Egyszerűsíteni akartuk a munkánkat, ezért kikötöttük, hogy a sokszög nem tartalmazhat lyukakat, és a csúcsok sorrendje az óramutató járásával megegyező irányban írja le az alakzatot. A kikötések után az "ear clipping" (magyarul nem tudom, hogyan lehetne frappánsan lefordítani) algoritmusra esett a választás, amely kellően egyszerű ahhoz, hogy implementálni lehessen.

Az algoritmus leírása

Egy háromnál több csúcsot tartalmazó sokszög három egymás után következő csúcspontját összekötve háromszöget kapunk. Ez a háromszög lehet "száj" vagy "fül" attól függően, hogy a háromszög alapja a sokszögen belül vagy kívül található (1. ábra).

Az ábrán az A csúcs egy száj, míg a B egy fül. A fül eltávolításával egy egyszerűbb sokszöget kapunk. Addig ismételgetjük a fülek eltávolítását, amíg egy háromszög nem marad.

Egy háromszögről úgy döntjük el, hogy fül-e, hogy megvizsgáljuk a körüljárási irányukat. Erre van érdekes módon a háromszög területének kiszámításával kapunk választ.:

T = (x2 - x1) * (y3 - y1) - (x3 - x1) * (y2 - y1)

A fenti összefüggés ugyanis más előjelű eredményt ad a körüljárás irányától függően.

Egy lépés viszont még visszavan. Az ábrán látható sokszög elég egyszerű, de találkozhatunk olyan elvetemült esettel is, ahol egy másik csúcs a vizsgálandó háromszög területén belül található. Ilyen esetben nem szabad eltávolítani a csúcsot.

A kérdés eldöntésére a háromszög összes szomszédos csúcsával és a vizsgálandó ponttal alkotunk egy-egy háromszöget, és megvizsgáljuk ezen háromszöget körüljárását. Ha az összes körüljárási irány azonos, a pont az eredeti háromszögen belül található (2. ábra).

Ha megvizsgáljuk az AEB és az AFB háromszögeket, láthatjuk, hogy más a körüljárási irányuk. Az algoritmus tesztelésére készítettem egy C#-os programot, ahova idővel további triangulációs algoritmusokat is be fogok építeni.

Algoritmus a GitHub-on.

Források:

http://softsurfer.com/Archive/algorithm_0101/algorithm_0101.htm#Modern%20Triangles
http://www.gamedev.net/topic/295943-is-this-a-better-point-in-triangle-test-2d/
http://cgm.cs.mcgill.ca/~godfried/teaching/cg-projects/97/Ian/applet1.html

Sokáig úgy gondoltam, a bioinformatika egyfajta tudományos megváltás. A nehéz és költséges kísérletek zajos eredményeiből a számítógépek, algoritmusok egyfajta letisztult eredményt adnak és olyan összefüggéseket láttatnak meg, amelyeket laboratóriumi munkák segítségével közel lehetetlen felfedezni. Ezt gondoltam egészen addig, amíg újgenerációs szekvenálásokkal nem kezdtem el dolgozni.

Itt ugyanis a még zajosabb eredmények születnek. Kezdjük ott, hogy maga a szekvenálás folyamata is sokkal zajosabb a Sanger-alapúnál. Ezt úgy ellensúlyozzák, hogy nagy mennyiségű rövid szekvencia részletet termelnek. Sajnos a mennyiség nem mindig csap át minőségbe. A bioinformatika ugyanis újabb zajt helyez az eredményekre. A rövid szekvenciák illesztése ugyanis pontatlanná válik ismétlődő szakaszok, mikroszatellitek és egyéb alacsony komplexitású régiók esetén.

A nagy mennyiségű zajos adatot nehéz tárolni, nehéz kiértékelni. A nukleotid polimorfizmusokat nehéz megkülönböztetni a szekvenálási hibáktól, a Chip-seq vizsgálatok esetén pedig a fehérje kötő helyeket nehéz leszűkíteni a nagyszámú találat miatt. A bioinformatika tehát nem, hogy segítene a kutatóknak, hanem újabb nehézségeket varr csak a nyakukba. Természetesen ez nem jelenti azt, hogy bioinformatika nélkül könnyebb lenne, mindössze azt, hogy megszűnt az a szerepe, hogy kiemeli az üveggyöngyöt a sárból. Már annak is örülönk, ha némi átlátszó műanyag kerül a szemünk elé.

Szerencsére a jövő nem tűnik vészesnek. A mostani trendek azt sugallják, hogy a kísérletes munka fogja levenni a terhet a bioinformatika válláról. A szekvenálók hosszabb és pontosabb readeket fognak készíteni. Ez azt jelenti, hogy nem kell olyan mélységben szekvenálni, mint manapság. Ez kevesebb tárolandó adatot jelent, és könnyebb feldolgozást. Egy hosszabb, kevesebb hibát tartalmazó szekvenciát algoritmikusan is könnyebb illeszteni a referenciához.

A kiindulási minták száma is kevesebb lesz. Nem véletlenül hallani az egy sejtet felhasználó módszerekről. A lambda-exonukleázok segítségével pontosabban fel lehet deríteni a fehérjekötő helyeket. Ezzel együtt úgy tűnik, hogy a bioinformatika háttérbe fog szorulni. Továbbra is szükség lesz rá, és lesznek olyan problémák, amelyek csak számítógépes úton lehet megoldani. De vége lesz a "futtatok egy Blastot és én vagyok a király" típusú munkáknak. Ezek bele fognak épülni a biológusok mindennapi feladatai közé.

Ezt támasztja alá, hogy több olyan integrált eszközt látni, mint amilyen a CLC Genomics Workbench, a Geneious, Galaxy, Taverna. A számtalan weboldalról nem is beszélve.

A bioinformatikusok algoritmusokat és eszközöket fognak fejleszteni, esetleg ismert lépésekből álló folyamatokat automatizálnak, de a közvetlen mintafeldolgozás meg fog szűnni.

Habár nem írtam jó ideje, nem teltek eseménytelenül a napok. Grassal pár hónapja kitaláltunk egy koncepciót, amire egy demót építve indulunk a Revision 2012 partin. A koncepció lényege, hogy egy olyan alkotást készítsünk, ami egyrészt élő szereplős, másrészt mégis generált animáció. Jó ideje gondolkodtam ugyanis azon, hogyan lehetne minél kevesebb programozásból elkészíteni egy produkciót.

A koncepció életképességét be kellett bizonyítani, és fel kellett tárni az esetleges hiányosságokat, ami némi kutatómunkát igényelt. Mivel egy része élő szereplős, fontos volt, hogy videóra vegyek bizonyos eseményeket, amelyeket azután számítógéppel feldolgozok. Ha a leírásom egyes helyeken homályos is, az csak azért van, hogy ne lőjjem le a poént.

A videó készítés volt az első nagyobb probléma. Nekem ugyanis nincs kamerám. Azt gondoltam, a mobiltelefon megteszi, ezért egy Amigás winchester beépítő keret és némi kábel kötegelő segítségével a telefont a fotóállványra szereltem. Sajnos nem csináltam képet róla, pedig szédületes látványt nyújtott. Azért, hogy a beépítőkeret meg ne sértse a telefon kijelzőjét, még két befőttes gumit is tettem a telefonra, mintegy tömítésnek.

Ezzel felszerelkezve elmentem videózni. Akkor még nem volt hó, de elég hideg volt. A telefon néha előbb félbeszakította a felvételt, minthogy leállítottam volna. A felvételek során megpróbáltam felidézni, mire emlékszem középiskolás talajtorna gyakorlataimból, aminek az lett az eredménye, hogy többször úgy a hátamra estem, hogy másnak mindenem fájt. Persze csak ezután vettem észre, hogy még a felvételek egy része is hiányzik.

Amelyik felvétel sikerült, azokkal sem lehettem maximálisan elégedett. A telefon színhűsége hagy némi kivánnivalót maga után. Ez egy közönséges felvételnél nem okoz gondot, de máris hihetetlen akadályt jelent, ha számítógéppel akarjuk feldolgozni.

Ez január elején történt, el is ment a kedvem a demó készítéstől. A problémákról beszéltem Grassal, aki felajánlotta saját fényképezőgépét. (Ez úton is köszönöm neki) A felbontás nem számított, de az állvány menet és a színhűség igen. A nagy havazások idején újra elmentem elvételeket készíteni. A hideg itt is kikezdte az akkumulátort, de nagyságrendekkel jobb minőségű felvételek születtek.

Nemrég sikeresen befejeztem az útófeldolgozó programot is, aminek hála három jelenet durva váza már elkészült. Ez elég motivációt jelentett, hogy folytassam a munkát. Egy komoly algoritmus implementálása még visszavan. Ez a trianguláció...

Folytatjuk...

Az egyik legtöbbet kutatott rákos elváltozás, a mellrák. Két génhez köthető a legtöbb rizikófaktor, a BRCA1 és BRCA2-höz. Az itt előforduló polimorfizmusok tehát rendkívül fontosak a kutatóknak és diagnosztáknak. Nem csoda, ha ezeket a változásokat adatbázisokba gyűjtik. Az egyik ilyen adatbázis a BIC. Mivel személyi adatokat is tartalmaz, jelszóval védett az oldal.

A teljes adatbázis letölthető tabulátorokkal határolt szövegként, amit aztán lehet vizsgálni. Feltéve persze, ha kitaláljuk, hogyan épül fel az adatbázis.

Az adatokból ugyanis tisztán látszik, hogy a tervezést az újabb tudományos eredmények elavulttá tették. Ahelyett, hogy újratervezték volna az adatbázist, inkább az új adatokat paszírozták a meglévő rendszerbe, furcsa titkosítás-szerű logikával. Azért, hogy másoknak ne kelljen a dekódolással szenvedni, leírom, hogy hogyan értelmezhetőek az adatok.

A legfontosabb adat, az adott variáció pozíciója. Ez a cDNS-en található nukleotid pozíciója. Megadják azt is, melyik exonban kell keresni. Időközben intron adatokat is elkezdtek feltölteni. Ha tehát exonnak I-3 van megadva, akkor az nem exon, hanem intron adat. A pozíció is módosul. 667+3 alakra, ami azt jelenti, hogy a második exon végétől még 3 nukleotid távolságra van a variáció. De néha a következő exon elejétől számolják a pozíciót, akkor értelemszerűen 1445-12 alakot fogunk felfedezni.

A mutáció jellege deléció, inszerció és SNP lehet. A deléciót a del kulcsszó jelzi. Előtte és után lehet szóköz, de akár el is maradhat. Ha rövid a szekvencia, akkor kiírják. pl: del AATGG, de ha túl hosszú, akkor csak a méretét írják ki. del 18. Hasonló a helyzet az inszerció esetén is (ins kulcsszó). A probléma akkor van, ha egy hosszabb szakasz egy rövidebbre cserélődik. Ilyen esetben láthatunk ilyen bejegyzést is: del 23 ins ATG. Az SNP-k jóval egységesebbek: nukleotid to nukleotid. Tehát A to G vagy C to T. Feltételezem, senki nem ellenőrizte az adatokat, miután felvitték, mert ilyen formát is láttam: A to G del G.

Vannak etnikai és nemzetség tárolására szolgáló mezők is. Valahol meg tudják mondani egyértelműen: pl Italian. néha viszont bizonytalanok: German? Egységes formát itt sem találunk. Az amerikaiakat például négyféle módon láttam leírva: usa, U.S.A, African American, United.

Az adatbázist jó ideje nem frissítették, de remek figyelmeztetés arra, hogy bárhol érhetnek minket meglepetések.

A hétvégén elhatároztam, hogy végigcsinálok egy tengerészgyalogos erőnléti felmérést. Nem kell komoly megpróbáltatásokra gondolni. Csak 5km futás, húzódzkodás és felülésből áll. Mindezeket a lehető leggyorsabban. A részleteket itt olvashatjuk.

A húzódzkodással kezdtem. 18-t tudtam megcsinálni. Utána szusszantam egyet, majd két perc alatt 83-szor felültem. Az első perc után tört meg a lendületem. Egy felüléshez utána már 5 másodperc kellett, de becsülettel végigcsináltam, majd két percig a földön feküdtem és csak lélegeztem. Mikor úgy éreztem képes vagyok felülni, felvettem a futócipőt és elkezdtem futni.

Három kilóméter után kezdtem kifulladni. Szerencsére ekkor jött egy lejtő, ahol újra felvettem az utazó sebességet. 27 perc 5 másodperc alatt futottam le.

A táblázat szerint egy 219 pont, ami a 27-39 éves korosztályban első osztályú eredmény. Minden esetre másnap nem éreztem magam első osztályúan. A vádlim egyetlen fájdalom csomóvá vált. Minden lépés után úgy néztem ki, mint egy hadirokkant. Nevetni nem tudtam, mert a hasamban is izomláz volt. Egyedül a húzódzkodás nem hagyott nyomot.

Ajánlom mindenkinek, mazoistáknak kötelező.