Az élet kódjai

A "nyílt forráskódú" bioscope verzió után megnéztem a kereskedelmi verziót is. Ezt elsősorban elosztott rendszereken lehet használni, webes felületen. Van lehetőség parancssoros futtatásra is, ami némiképp idegen lehet attól, aki rendszeresen futtat GNU/Linux alól parancssoros programokat.

A program nagy előnye, hogy szemben más alkalmazásokkal, itt az egyes programokat "összefűzhetjük" és kötegelt elemzéseket csinálhatunk anélkül, hogy összetett paranscsori szkripteket írnánk és a különböző formátumok között konvertálnánk. A webes környezet használatára nem térek ki, mert az amolyan klikkelj és futtass filozófiát követ.

Parancssorban teljesen más a helyzet. A rendszer rendelkezésünre bocsát egy demos könyvtárat, amiben az összes műveleti lépés készen várja, hogy elindítsuk. Az egyes paramétereket .ini fájlokon keresztül lehet beállítani, mint Windows 3.1 alatt. Igyekeztek mindent úgy elkészíteni, hogy a lehető legkevesebb erőforrás segítségével lehessen használni a programot. Az ini fájlok testreszabása után csak egy ./run.sh parancsot kell kiadni és az elemzés elindul.

Sajnos pont ezzel sikerült megfosztani a felhasználót a folyamatok összefűzésének lehetőségétől. Nagyon elszánt felhasználók talán átnézhetnék a run.sh parancsfájlt, aminek felépítéséről nincs semmi sem a dokumentációban. Sajnos nem volt annyi időm, hogy ezt megtegyem, ezért én úgy fűztem össze a programokat, hogy egy .ini állomány másoló programot készítettem. Nem a legjobb választás, de célnak megfelelt.

A Bioscope programjait továbbra is gyengének találom. Ezt valószínűleg a készítők is érezhetik, mivel például a readek referenciára illesztésére inkább a BFast-ot ajánlják, mint saját fejlesztésű programjukat.

Az egyetlen előnye a Bioscope-nak, hogy elfedi a felhasználó elöl az elosztott gépek indításával és leállításával, az adatok mozgatásával járó bonyodalmakat.  A végpontokról gyakorlatilag semmilyen információt nem kellett tudnom, mikor futtattam a programokat. Ez mindenképp pozitívum. Sajnos a telepítés nehézségeiről nincsenek információim, tehát nem tudom, hogy mennyivel nehezebb, mint ha valaki Condort, Oracle Grid Engine-t vagy Hadoopot használna.

Jó estét, jó szurkolást. Mai félnehéz súlyú mérkőzésünkön két igazi nagyágyú méri össze tudását. A tét nem kevesebb, mint a CLCBio Genomics Workbench elindítása. A mérkőzés helyszínét az Amazon biztosítja. Az idő szokás szerint felhős.

A kék sarokban a címvédő Windows Server 2008. Régi játékos már, számtalan apró fogást ismer, amivel nem egy kiváló játékost küldött padlóra. A piros sarokban a kihívó, Travis. Nem sokat tudunk erről az új játékosról. Korábbi meccsein szívós és kitartó volt. Majd meglátjuk, hogy a sok Linuxos meccs után mit kezd egy számára ismeretlen ellenféllel. Google edző a ringen kívül figyeli a mérkőzést.

Megszólal a gong, a játékosok a ring közepén vannak! Óvatosan kerülgetik egymást. Windows arcáról semmit nem lehet leolvasni. Travis RDesktoppal kapcsolódik, Windows beengedi, de semmi komoly nem történik. Travis kezdeményez, megnyitja a böngészőt. Internet Explorer feljön. Windows arcán halvány mosoly fut át, mint aki számított erre a lépésre. Travis megpróbálja letölteni a Workbench-et! Merész lépés volt egy kezdőtől. De nem fut a JavaScript! A letöltés meghiúsult! Ügyesen védett Windows. Még sok meglepetést fog tartogatni nekünk ez a mérkőzés, biztos vagyok benne! Travis rezignáltan veszi tudomásul. Az oldal forráskódjából kiszedi a kívánt címet, és már meg is kezdi a program letöltését. Pontosabban kezdené, mert Windows megtiltja a futtatható állományok letöltését!

Travis fogást keres ellenfelén. Vezérlőpult, Internet beállítások körül forgolódik az egérrel. Igen, jó helyen keresgél. Engedélyezi a letöltést. Windows néhány popup ablakkal vág vissza, de mindez csak elterelés. A letöltés ezután sem megy. Még zöldfülü ez a fiú!. De nem, az UAC háza táján turkál. Igen, igen. Micsoda jobb horog! Az UAC kikapcsolva. Windows láthatóan megtántorodik. A bíró közbelép és újraindítást rendel el. Windows úgy támolyog a sarokba. Travis magabiztosan mosolyog.

Második menet.

A második menetben Travis magabiztosan kezd. Ismét megkezdi a letöltést. Nem veszi észre, hogy a kikapcsolt UAC ellenére a JavaScript továbbra sem aktív a böngészőjében. Ez nagy hiba, csak a győzelmét látja, az intő jeleket nem. Letöltés, és UAC ide-vagy oda, az továbbra sem megy. Travis kezdi elveszíteni a türelmét, ami szintén arra utal, hogy tapasztalatlan játékos. Ismét az Internet beállítások körül ólálkodik. Mindent engedélyez, amin piros jel van és biztonsági problémára figyelmeztet. Nem gondolkodik, csak klikkel. Második hiba a mérkőzés során! Miután bezárja a Vezérlőpultot, váratlanul újra megnyitja. Már kezdi kapisgálni, úgy látom. Windows az első menetben hátrányba került, de most mosolyog. Igen, van is rá oka. A változtatások ellenére a Vezérlőpulton, mintha nem is állítottak volna át semmit. Travis sem érti. Leengedi a karját, mire Windows hatalmasat üt állcsúcsára. Travis elveszti egyensúlyát. A bíró közbelép. Hármat számol, de Travis feláll, készen, hogy folytassa a mérkőzést. A gong ismételten egy menet végét jelzi. Travis a sarokba tántorog. Google edző folyamatosan súg neki, bárcsak hallanánk, hogy mit!

Harmadik menet

Travis sokkal nyugodtabb. Ha most látnánk először, még azt is hihetnénk, hogy profi játékos. Ismét az internet beállítások felől támad. Most alapértelmezetté teszi a változtatásokat és nem csak az alapértelmezett profilban, hanem mindenhol. Nem elegáns, nagyon nem elegáns. Olyan, mintha már személyes ügy lenne. Már nem a győzelem a cél, hanem az ellenfél szétzilálása. Windows erőtlenül figyelmeztető üzeneteket küld, de ezeknek már nincs semmi hatása. Windows hátrál, mintha nem tudna mit kezdeni ennyi támadással. Travis letölti a CLCBio bővítményét, és sikeresen beilleszti a Workbenchbe. Újraindítja azt. És most jön Windows ellencsapása! A bővítményt a neten keresztül kellene hitelesíteni, de mivel Travis távoli asztalról jelentkezett be, ezért Windows ezt egy hibaüzenettel meggátolja. Bumm! Travis a padlón.

Most értette meg, hogy nincs esélye a győzelemre. Amazon ringben csak távolról lehet bejelentkezni. A hitelesítési problémáról pedig a CLC is tud, ezért nem is támogatják a Windows Server semmilyen verzióját! Minden lépés csak trükk volt Windows részéről, hiszen biztos volt, hogy ő győz. Mégis játszotta a sérült, beteg, gyenge ellenfelet. Ezt nevezem én versenyrutinnak! Most a boldogan sétál a ringben és ünnepelteti magát a tömeggel. De mi ez? Travis felkel. A bíró közbe akar lépni, de ellökik! Travis terminálja a virtuális gépet! Windows eltűnik, mint egy szappanbuborék. A közönség elhülve figyeli a sportszerűtlen magatartást. A szövetség biztosan eltiltja ezt a fiút a további Windows mérkőzéstől. Travis, mintha nem is bánná...

Véletlenül akardtam rá a PHDComics-ra, de azonnal rákaptam. Sejtettem már Asimov regényéből is, hogy a PhD hallgatók élete a föld különböző pontjain annyira nem is különböznek egymástól. Így egyben olvasni és nevetni rajta egyszerűen felemelő érzés.

Rögtön eszembe jutottak a rég elfeledett problémák, melyek akkor a világot jelentették és szembesültem azokkal a problémák, melyeket most élek át. Ajánlom mindenkinek.

A legújabb demónknál elhatároztam, hogy OpenGL 4.1-t fogok használni. Az interneten fellelhető dokumentációk jelentős része még a régebbi verziószámú rendszerre érhető el, ezért előfordul, hogy értetlenül nézek a képernyőre és nem értem, miért nem jelenik meg semmi.

Most, hogy a korábbi módszerek helyett minden shaderből megy, egyrészt jó, mert megadja azt a szabadságot, amit elvárhatok a rendszertől, másrészt elvesz néhány kényelmi szolgáltatást. Értem ez alatt a glRotate (forgatás) és glTranslate (eltolás) függvényeket. Mivel nem erős oldalam a matematika, ezek elvesztése fájt.

A három dimenziós alakzatokat puffereken keresztül lehet megadni, ahol később mi magunk mondjuk meg, hogy az adott puffer milyen szerepet töltsön be. Tehát vázlatosan valami ilyesmi kódot lát az ember:

glGenBuffer...
glBindBuffer...
glBufferData...

Ezzel nem is volt különösebb problémám. Megadunk egy puffert az alakzatunk csúcspontjának, a normálvektor irányának és a textúrák koordinátájának. Ezt szépen össze lehet fogni olyan függvényekbe, mint loadMesh() és utána minden demóban lehet használni. Ahol nekem most problémám akadt, mindezt hogyan mondjuk meg a shaderünknek?

A dokumentáció és a példaalkalmazások alapján előttem két út rajzolódott ki:

1. A shader linkelése előtt explicit megadjuk, hogy hányadik puffer melyik shader változónak felel meg, a glBindAttribLocation() függvény segítségével.
2. Linkelés után lekérdezzük a shader változó azonosítóját (glGetAttribLocation), majd hozzákapcsoljuk a megfelelő puffert (glBindBuffer, glVertexAttribPointer, glEnableVertexAttribArray).

Az első megoldás kényelmes, de én egy általános shader betöltőt akartam írni, ami nem foglalkozik azzal, hogy milyen változók vannak a shaderben és azoknak mi a szerepe. Csak betölti a shadert valami loadShader() függvénnyel, ami egyedül a fájl nevét kapja meg. Megjegyzem, még ebben az esetben is lehet használni az első módszert, de a glBindAttribLocation() meghívása után ki kell adni egy glLinkProgram() utasítást is. Tehát valami ilyesmi kódunk lesz:

shaderprg = loadShader("winnershader.vert", "winnershader.frag"); // van benne glLinkProgram
glBindAttribLocation(shaerprg, 0, "coolvariable");
glLinkProgram(shaderprg);

Ez viszont nem tetszik. Miért hívjak meg többször egy függvényt? A második módszer jobban tetszett. Meg is írtam a rutint. És nem működött. Ez azért is érdekes, mert Norbert Nopper kollégának működött. Már kezdtem azt hinni, hogy kénytelen leszek a béna első módszert használni, amikor Nopper programját tüzetesen megvizsgálva észrevettem a megoldást. Nevezetesen ki kell adni a glBindVertexArray-t is. Utólag belegondolva logikus is, hiszen több VertexArray-el is dolgozhatunk.

A módosítás hatására a program az elvárt végeredményt mutatta.

Ugyancsak fontos, hogy megfelelő időben aktiváljuk shader programunkat. A glUseProgram mindig előzze meg a glGetUniformLocation és glUniform parancsokat, különben GL_IVALID_OPERATION hibaüzenetet kapunk, amit nehéz felderíteni.

Néhány bölcsesség:

• Ne bízz abban a bioinformatikusban, aki nem tudja mennyi memória van a gépében.
• A bioinformatikus legnagyobb ellensége a Word fájlban átadott szekvencia.
• Kerüld azt a programozót, aki kiadványszerkesztőben ír programot és kézzel színezi a kulcsszavakat.
• Hamar cikkírás ritkán impaktos.
• Vigyázz azzal a bioinformatikussal, aki Windowst használ! Vagy kókler (nem tud Linuxot használni), vagy nagyon profi (úgy használja a Windowst, mint más a Linuxot)
• Soha ne sértegess Machintosos bioinformatikust.
• A jó bioinformatikus nem tudja, mi az Excel fájl.
• Ha a jó bioinformatikus tudja is, mi az Excel fájl, soha nem fog neked készíteni egyet sem.
• A PowerPoint nem poszter készítő program.
• A Word nem képszerkesztő.
• A Word nem honlap készítő.
• Az Excel nem adatbázis.
• A rossz bioinformatikus minden feladatra legalább két programot használ.
• A még rosszabb bioinformatikus az összes feladatra egy programot használ.
• Aki még ennél is rosszabb, az mindenre Microsoft Office programokat használ.
• Ne taníts olyan bioinformatikust, aki ezt kérdezi: "Ez a kódolás, ez muszály?"
• Ha sok statisztikai tesztet futtatsz, mindig használj többszörös teszt korrekciót.
• Ha azt kérik, hogy ne használj többszörös teszt korrekciót (mert nincs elég szignifikáns eredmény), akkor is használd.
• A főnök sürgetése nem lehet indok az új módszerek meg nem ismerésére.
• Ha tudod, hogy rossz a bemeneti adat, akkor is bizonyítsd. Több a meló vele, de könnyebben elfogadják.
• Ne félj hibázni. A hibától való félelem csak paralizál, míg a hibából tanulhatsz.

A listát frissíteni fogom.

Elérkeztünk az utolsó részhez. Több gyakorlatot nem terveztem, de lesznek még CUDA-val kapcsolatos bejegyzések. Elég a bevezetőből, vágjunk bele.

A kódunk még messze nem tökéletes. Először csak rövid optimalizációkat végzünk. A szögfüggvényeknek például van a CUDA magokon futó változata. Ezt a math_functions.h fejléc állományban elfedik előlünk, hogy könnyű legyen a kód migrálása, de jobb, ha ezt magunk csináljuk, nem bízzuk egy fordítóra, amit nem mi írtunk :-) Ezért nézzük át a device_functions.h fejlécállományt. Találunk ott egy érdekes függvényt: __sincosf(). Tehát egy lépésben kiszámolhatjuk a színuszát és a koszinuszát ugyan annak a szögnek.

Általánosságban elmondható, hogy a két aláhúzással jelzett függvények eszköz kódok. Amikor csak tehetjük, használjuk őket. Szorzás helyett is nyugodtan használhatjuk az __fmul_rn függvényt. Ezek alapján az új distance függvényünk a következőképp fog kinézni:

__device__ float distance(float2 p1, float2 p2){
   float dx = p1.x - p2.x;
   float dy = p1.y - p2.y;
   float x2 = __fmul_rn(dx,dx);
   float y2 = __fmul_rn(dy,dy);
   float su = __fadd_rn(x2,y2);
   return( __fsqrt_rn(su) );
}
 

Megmondom őszintén, nem tudom, mit jelent a függvények végén az _rn. Van másik három rz, rd, ru is, nem tudom, hogy mi a különbség közöttük. Amint lesz róla információm, kijavítom ezt a bejegyzést.

__device__ void collision(float2 *p1, float2 *p2, float angle){
   float p1x2 = __fmul_rn( p1[0].x, p1[0].x );
   float p2x2 = __fmul_rn( p2[0].x, p2[0].x);
   float p1y2 = __fmul_rn( p1[0].y, p1[0].y);
   float p2y2 = __fmul_rn( p2[0].y, p2[0].y);

   float m1 = __fsqrt_rn( p1x2 + p1y2);
   float m2 = __fsqrt_rn( p2x2 + p2y2);
   float d1 = atan2f( p1[0].y, p1[0].x);
   float d2 = atan2f( p2[0].y, p2[0].x);

   float sa, ca, sb, cb; /* sin and cos of d1 - angle */

   __sincosf(d1 - angle, &sa, &ca);
   __sincosf(d2 - angle, &sb, &cb);

   float p1newx = __fmul_rn(m1,ca);
   float p1newy = __fmul_rn(m1,sa);
   float p2newx = __fmul_rn(m2,cb);
   float p2newy = __fmul_rn(m2,sb);

   __sincosf(angle + 3.14f / 2.0f, &sa, &ca);
   __sincosf(angle, &sb, &cb);

   p1[0].x = __fmul_rn(cb,p2newx) + __fmul_rn(ca, p1newy);
   p1[0].y = __fmul_rn(sb,p2newx) + __fmul_rn(sa, p1newy);
   p2[0].x = __fmul_rn(cb,p1newx) + __fmul_rn(ca, p2newy);
   p2[0].y = __fmul_rn(sb,p1newx) + __fmul_rn(sa, p2newy);
}
 

A collision függvényünket is megváltoztathatjuk. Itt ráadásul áttekinthetőbbé tettük a paramétereket. A mutatók tömbként való használata nem véletlen, ha másképp használjuk őket, akkor "error: expression must have class type" hibaüzenetet kapunk fordítási időben.

Utolsóként a calcParticlePos függvényünk következik. A globális memória elérése nem túl ideális, egyrészt a lassabb elérés miatt, másrészt a konfliktusok miatt. Előfordulhat ugyanis, hogy több szál próbál meg módosítani egy memória területet.

A memória elérés gyorsítására lehet használni a megosztott memóriát. Annak bemutatására most nem vállalkozom.

Egy érdekes cikkre bukkantam a Nature hasábjain (itt). Röviden a lényege, hogy a kutatók többsége képtelen normális kódot írni. Nem ellenőrzi, dokumentálják a programosorokat, ezért a vége jobb esetben nem működő program, rosszabb esetben hibás eredmény, amit neves újságok hasábjain publikálnak.

Szeretném hinni, hogy én nem tartozom közéjük, amire az ad okot, hogy dolgoztam programozóként is, nem csak kutatóként. Ha viszont az itt feltüntetett kódjaimban vagy a demóim forráskódjában valaki oltári nagy ostobaságot talál, akkor annak a cikkben leírtak az okai.

Komolyra fordítva. A munkám során én is találkoztam ilyen esetekkel. Az első egy hipergeometrikus eloszlást számolt GO azonosítókra. Azt vettük észre, hogy a program meglepően lassú. Megnéztem a forráskódot és meglepődve tapasztaltam, hogy minden egyes rendezés során az adatokat fájlba írta. Ez elég rossz hír volt, de a mégrosszabb az volt, hogy a program szerzője nem ismerte a hasítótáblákat, helyette tömböt használt. Minden egyes alkalommal végigjárta a teljes tömböt, ha egy elemet meg akart találni. Természetesen ezt is fájlba írta, majd visszaolvasta onnan. Mondanom sem kell, hogy a fenti két hiba kijavítása után 40-szeres sebességnövekedést értünk el.

A másik esetben a Java program tartalmazott C programrészletet, aminél súlyos memóriaszivárgás volt. Ez csak bizonyos hosszúságú szekvenciáknál okozott szegmentációs hibát. Az utolsó esetben olyan programmal találkoztam, ami gyakorlatilag érthetetlen volt a számomra. Bonyolult volt a matematikai modell is, amit alkalmazott (legalábbis nekem), de a program felépítése ezt tovább bonyolította. Az összetettséget jól példázza, hogy bárki, aki a kódhoz nyúlt és javított benne valamit, két másik hibát ejtett.

A cikkben említett jelenséget tehát én is megtapasztaltam. Kérdés, hogy mit lehet tenni ellene. Először is, ne tegyünk fel mindent egy lapra. Ha egy program kiadott egy eredményt, ne higgyük, hogy most miénk lesz a Nobel-díj. Használjunk több programot. Ahogy a laboratóriumi munkában sem fogadják el, ha csak Chip-kísérletet végznek és nem validáljuk azt QT-PCR-al, mi se dőljünk hátra, ha egyetlen program, egyetlen beálításokkal kiad egy eredményt.

Most Blastot fordítok, ezért van némi időm sztorizgatni. Például egy baktérium szekvenálása során kaptunk egy gént, ami elé egyedi volt, hogy a Blast ne adjon egyértelmű ereményt, ezért halvány sejtelmünk sem volt róla, hogy mi lehet a szerepe. Több prediktáló programot is kipróbáltunk, míg végül egyszer csak azt kaptuk, hogy transzmembrán proteint kódol. Ez sem volt egyértelmű, mert amint megváltoztattuk kicsit a program paramétereit, rögtön eltűnt az eredmény. Természetesen hozzá kell tennem, hogy ezt az eredményt kísérletesen ellenőriztük és olyan szerencsénk volt, hogy igazolni tudtuk.

Végezetül még egy tanács. Ha mi magunk írunk programokat, ne féljünk tanulni. Ne higgyük, hogy csak azért, mert elméleti algoritmusokat vagyunk képesek működő programkóddá varázsolni, máris mi vagyunk a programozás nagymesterei. Ha pedig hibás programra bukkanunk, javítsuk ki, vagy írjunk újat, mert senki nem csinálja meg helyettünk.

Még 2007 tavaszán, a SceneCon nevű demoshown láttam meg az Efikát és mondhatom szerelem volt az első látásra. Egy csendes, alacsony fogyasztású, mérsékelt (mások szerint gyenge) teljesítményű számítógép, ami a legegyszerűbb igényeket kielégíti.

Több, mint két évet kellett várnom rá, hogy az enyém legyen. Ez alatt az idő alatt az emberek többsége elpártolt a kedves kis géptől, a gyártását beszüntették. Használtan jutottam hozzá (egy váláson már túl volt), haza is vittem. Mint a kapcsolatok többségénél, itt is igaz volt, hogy lakva ismeri meg a másikat az ember. A filigrán kis házból hiányoztak a csavarok, amerikai típusú hálózati csatlakozót kaptam hozzá és két olyan videokártyát, amelyik közül egyikkel sem ment.

A legegyszerűbben a hálózati csatlakozó problémáját oldottam meg. A gép energiaellátásáról egy laptop tápegység gondoskodik (mondtam, hogy alacsony fogyasztású), ezért használtan vettem egy három ágú tápkábelt, amivel máris megetethettem árammal.

A videokártyákkal is voltak problémák. Mint említettem, kettőt kaptam. Egy Nvidia GeForce MX440-t és egy Ati Radeon 9200-t. Az Nvidiás belefért a kis házba, de nem volt hűtése és képtelen volt elviselni azt a felbontást, amit a Linuxos telepítő beállított neki. Az Ati kártya képes lett volna rá, de az nem fért bele a házba, sőt igazából az alaplap néhány kivezetése is akadályozta. Kellett szerezni egy vékonyabb kártyát. Újabb használt cikk keresés. Végül szert tettem egy Ati 9250-re, ami már illett a kisasszonyhoz. Akitől vettem, nem tudott feles takaró lemezt adni hozzá, ezért kedvenc többfunkciós fogómmal addig faragtam a lemezt, amíg a nem illeszkedett a házba.

A gép két USB-t tartalmaz. Az egyik értelemszerűen a telepítés során a pendrive-t fogadja, a billentyűzetnek és az egérnek már csak egy marad. Szereztem egy USB elosztót is, de az alacsony áramfelvételű gép USB-je nem ad elegendő feszültséget, hogy egy USB elosztót üzemeltessen (aminek nincs saját áramforrása). Ekkor felvettem macsó modoromat és kijelentettem, hogy nem kap új USB elosztót, enélkül fogok boldogulni.

Első körben Linuxot akartam rá telepíteni. A Genesi elérhetővé tett egy Debian-t, amit állítólag könnyedén lehet telepíteni a gépre, Sajnos a hálózatról akarta leszedni a szükséges kernelt, ami ennyi idő távlatából már sehol nincs fent, a telepítés ezen lépését pedig nem tudtam megkerülni. Második jelentkező a Slackware volt. Ez a a partíciók formázásánál nem tudott tovább lépni.

Végül a MorphOS mellett döntöttem. Akár milyen hihetetlen, ezt sem tudtam telepíteni. A grafikus környezetet csak billentyűvel kezeltem, a TAB és a nyilak gyors váltogatásával, de a telepítés gomb valami miatt nem volt aktív, ezért ezzel a rendszerrel is befürödtem.

Azt csak mellékesen jegyzem meg, hogy elsőre soha nem ismerte fel a rendszerindítás után a pendrive-ot. Kétszer-háromszor kellett neki kiadni az uboot parancsokat, hogy felismerje, amit fel kell ismernie.

Végül bármennyire is nem szeretem, a Suse Linux mellett döntöttem, ami még könnyebb telepítést tesz lehetővé. A dokumentáció részletesen leírja, hogy mit kell csinálni a telepítés során. Követtem is a lépéseket, de az már nem derült ki, hogy újraindítás után mit kell csinálni. A merevlemezen volt a rendszer én pedig ültem a gép előtt és azon gondolkodtam, mi legyen a következő lépés.

Természetesen a boot hd:0 boot/efika sorokkal kezdtem. Ez minden áron kereste a nem létező /dev/sda3-t. Volt még két másik kernel is a boot partíción efika19 és efika19genesi. Ezek csak kernel pánikoltak. Végül egy fórumban fedeztem fel a lényeget: root=/dev/sda1. Persze, magamtól is kitalálhattam volna.

Elindítottam a rendszert, szépen be is jött az üdvözlő képernyő, majd rájöttem, hogy nem tudom sem a felhasználói nevet, sem annak jelszavát, amivel beléphetek. Ha lenne egy CD meghajtó, máris indítanám a Knoppixot, de így? A helyzet korántsem olyan reménytelen. A rendszerfájlok ugyanis megvannak egy tömörített állományban. Ezt kicsmagoltam, és máris böngésztem az /etc/passwd állományt. Meg is találtam, amit kerestem: felhasználónév: genesi, jelszó: genesi. A rendszergazdai jogosultságnak is ez a jelszava! Hurrá!

A kis hölgy ellenállását sikerült megtörni. Most már olyan, mint egy kezes bárány. Alacsony fogyasztásának hála rengeteg lehetőség van benne. Első lépésként kíváncsi vagyok, hogy megy-e a TV kimenet a videokártyán (10.3 Suse miatt nagy rá az esély, hogy nem). Utána megnézem, mennyire szereti a webkamerákat.

Nem kétséges, hogy azoka, akik tesztelési és elemzési célra újgenerációs szekvenálási adatokat akartak szerezni, először a SRA-t keresték fel. A pénzügyi problémák viszont utólérték ezt a szervezetet is, mint az ebből a blogból kiderül. Valószínű, hogy bezárják ezt az adatbázist.

Miért is jelent ez problémát? Először is, az újgenerációs szekvenálás hatalmas mennyiségű adatot termel. A marketing szövegeken túl ugyanis elég rossz minőségű szekvenciákat produkálnak ezek a készülékek (legalábbis a régi típusú Sanger szekvenáláshoz képest), amit úgy próbálnak orvosolni, hogy többször szekvenálnak meg valamit. Ezt hívják lefedettségnek. Egy 10-szeres lefedettségű emberi szekvencia elérheti a 30GB-ot is, tömörítve. Érthető módon senki nem szeret a munkaállomásán ekkora mennyiségű adatot tárolni. Ehhez még hozzájönnek az elemzések során kelektkezett állományok, és máris ott tartunk, hogy feléltük egy átlagos merevlemez kapacitását.

A másik probléma, hogy ezeknek az adatoknak elérhetőnek kell lennie mások számára is. Egyrészt, hogy ellenőrizhessék azokat, másrészt további vizsgálatokat végezhessenek. Ezért nem elég, ha ezek az adatok ott porosodnak bármilyen adathordozón, az interneten elérhetőeknek kell lenniük.

Ez a hely pedig sokáig az SRA volt. Rajta kívül van még az ENA, de engem személy szerint nem nyűgözött le a megtalálható adatok mennyiségével, bár akadnak érdekes szolgáltatásaik is.

Mit lehet tenni, hogy kiváltsuk az SRA-t? Két fő csapásirány lehetséges. Az egyik a centralizált adatbázis, a másik a decentralizált.

Centralizált megoldások

• Jön egy új szervezet, megszámlálhatatlan mennyiségű tárhellyel és egyszerűen átveszi az SRA helyét. Például a fent említett ENA
• Mindent felhő alapú gépekre helyezünk, például az Amazonra.

Decentralizált megoldások

• Biotorrent. Nem csak a legújabb Hollywoodi filmeket szerezhetnénk be a hírhedt fájlcserélő szolgáltatáson keresztül, hanem kedvenc szekvenciánkat is. Csak legyen, aki seedel. :-)
• dCache-szerű rendszer fejlesztése. A fizikusok is sok adatot termelnek, és ők ezzel oldották meg az adatelérést.

Őszintén szólva, az előző programunkban több hiba is van, de talán segít megérteni, hogy a CUDA programozás új gondolkodást kíván. Nem elég, hogy a ciklusokat kernelekre cseréljük. Az ütközős program a struktúrális programozás szellemében készült. Nem csak programhiba, hanem metodikai hiba is van benne. Most nézzük, hogyan tudjuk kijavítani ezeket.

Az SDK tartalmaz egy hibakereső programot cuda-gdb néven. A --device-debug opció segítségével hibakereső információk kerülnek a fordított kódba, szintje 0-3-ig terjedhet. Ezután használhatjuk a cuda-gdb programot, ami szintén az SDK része. Sajnos grafikus alkalmazásoknál nem használható, így használatától el kell tekintenünk.

A második, diagnosztikai módszer, amit minden bizonnyal mindenki ismert, a megjegyzések elhintése vagy a képernyőre vagy egy fájlba. A CUDA SDK tartalmaz egy simplePrintf példaprogramot, amivel üzeneteket helyezhetünk a képernyőre. Személy szerint nem kedvelem, de ettől még lehet, hogy jó hasznát veszi az ember.

Kreatív módszerekkel viszont élhetünk. Még annak idején, amikor nem voltak ilyen nagyszerű shader debugger programok, a programozók a beépített OpenGL változóknak adtak feltűnő értékeket, ha valami gyanús történt. Pl. fragment shader esetén vörös színt, vertex shader esetén a csúcspontot eltolták jobbra. Hasonló módszert mi is alkalmazhatunk. Adjunk hozzá még egy cudaGraphicsResource-t, amiben mondjuk a színeket tároljuk. Ha valami furcsaság történik, változtassuk meg a részecske színét!

A teljes programsort most nem írom ide, majd ha mégis igény lesz rá, akkor belinkelem. A kernelt viszont bemásolom. A lényegi műveleteket úgyis az végzi. A c tömbben a színeket tárolom:

__global__ void calcParticlePos(float2 *p, float2 *v, float3 *c){
   int index = threadIdx.x;
   int i;

   /* Collision with the wall */
   if(p[index].x > 1.0f){
      p[index].x = 1.0f;
      v[index].x *= -1.0f;
   }

   if(p[index].x < -1.0f){
      p[index].x = -1.0f;
      v[index].x *= -1.0f;
   }

   if(p[index].y > 1.0f){
      p[index].y = 1.0f;
      v[index].y *= -1.0f;
   }

   if(p[index].y < -1.0f){
      p[index].y = -1.0f;
      v[index].y *= -1.0f;
   }

   /* Collision with each other */
   for(i = 0; i < PARTICLENUM; i++){
      if(i == index) continue;
      if(distance(p[i].x, p[i].y, p[index].x, p[index].y) < COLLIDEDIST){
         c[i].x = 1.0f;
         c[i].y += 0.01f;
         c[i].z += 0.01f;
         c[index].x = 1.0f;
         c[index].y += 0.01f;
         c[index].z += 0.01f;
         float angle = atan2f(p[i].y - p[index].y, p[i].x - p[index].x);
         collision(&v[i].x, &v[i].y, &v[index].x, &v[index].y, angle);
      }
   }

   p[index].x = p[index].x + v[index].x;
   p[index].y = p[index].y + v[index].y;

}

A program futása után már érezhető a probléma. A részecskék a kelleténél többször ütköznek. Ahelyett, hogy a részecskék 100 ütközés után érnék el a fehér színt, már az első ütközés alkalmával kifehérednek. Ennek az oka, hogy a CUDA magok igaz párhuzamosan futnak, de nem azonos idő alatt fejezik be a futást. A másik ok, amit szemfülesebb olvasók már bizonyára észrevettek, hogy a ciklusunk rossz! Minden egyes ütközés kétszer zajlik le. Tegyük fel, hogy a 231. részecske és a 42. részecske ütközését vizsgáljuk. Először lefut a 42. CUDA kernel, ahol a ciklus segítségével megtalálja az 231. részecskét, amivel ütközött. De a 231. CUDA kernel is lefut, és ő is megtalálja a 42. részecskét, amivel ütközik. A vizsgálat kétszer lesz igaz. Írjuk át a for ciklust a következőkre: for(i = index + 1; i < PARTICLENUM; i++). Ezzel az utána következő sorban található feltételt is kiváltottuk.

Ha lefuttatjuk a módosított kódot, akkor egy másik anomáliával találkozhatunk: egyes részecskék "összeragadnak" és egymás körül keringenek. Ez azért van, mert az ütközés után nem tudnak elég távol kerülni egymástól, ezért a következő ciklusban is ütköznek.

Mint említettem, az egyes szálak nem azonos sebességgel futnak. A fenti kódunkban ez okozhat problémákat. Kiküszöbölésükre találták ki a __syncthreads() függvényt. Használata csökkenti a teljesítményt, de segítségével elérhetjük, hogy a szálak nem versenyezzenek. Közös memóriaterület használata esetén nagyon hasznos tud lenni. Helyezzünk el egy ilyen függvényt nyugodtan a ciklus előtt.

A következő részben optimalizálni fogjuk a programunkat.

A kütyük számának emelkedésével egyre több olyan eszköz van nálunk, amit nem haszálunk ki teljesen. Értem én ez alatt, hogy több különböző eszköz is képes ellátni egy bizonyos feladatot, csak más hatékonysággal, ami már elég ahhoz, hogy mind a kettőt cipelni kelljen. Konkrétumokat említve, itt vannak az okos telefonok. Tárolnak neveket, címeket, fényképeznek, megjelenítik a népszerű irodai programcsomagok állományait, pdf-t. Lejátszák a zenét és a videókat. Azután ott vannak a e-book olvasók. Ezek is megjelenítenek pdf-t, némelyikük zenét is lejátszik. A laptopok is olvasnak minden állományt, lejátszanak zenét, filmet. Tárolhatnak címeket, telefonszámokat. Újdonság, hogy már tábla gépek is vannak. Filmnézés, zene hallgatás, dokumentumok olvasása, e-book megjelenítés, adattárolás, fényképezés mind szerepel a repertoárjukba.

Ezért gondolom, hogy a tábla gépek és az utánuk piacra lépő jövendőbeli kütyüknek inkább divat felhangja van, mint tényleges haszna. Így éreztem akkor is, mikor megjelent az iPad. Erre is rácuppant kicsi és nagy, bizonygatták internet szerte a hasznát és haszontalanságát egyaránt. Viszont néha előfordul, hogy valaki képes megtalálni ezen eszközök potenciális hasznát. Olyan hasznot, amit más kütyüvel nem vagyunk képesek elérni.

Például nem lenne nagyszerű, ha egy ilyen tábla gépen nézegethetné valaki az általa vizsgált genomot? Mentesülne a laptopon való szerencsétlenkedéstől, a mobiltelefon apró kijelzőjétől. Csak megérintené a genomot...

Pontosan ez motiválta a JBrowse programozóit is, akik elkészítették a programjuk iPad kompatibilis verzióját

Az eddigi példaprogramok, valljuk be, nem voltak túl látványosak. Joggal kérdezhetnék tőlem, hogy miféle demoscene ember az, aki csak ilyen unalmas példaprogramokat tud bemutatni. Teljes mértékben igazat kell adnom. Ezennek törlesztem adósságom, és egy olyan programot készítünk, ami OpenGL-t is használ. Méghozzá egy csomó pontot fogunk dobálni a képernyőn. Ez nem nagy kaland még a CPU-nak sem, de megbolondítjuk azzal, hogy minden pont ütközhet egymással, nem csak a fallal. Ez már elég érdekesen hangzik? Ha igen, akkor vágjunk bele.

#define GL_GLEXT_PROTOTYPES
#include <stdio.h>
#include <stdlib.h>
#include <GL/glut.h>
#include <GL/gl.h>
#include <cuda_gl_interop.h>

#define WIDTH 1024
#define HEIGHT 768
#define PARTICLENUM 500
#define COLLIDEDIST 0.005f

GLuint pointBuff;
struct cudaGraphicsResource *pointBuff_CUDA;
float4 *particles;

/* Calculate distance of the points */
__device__ float distance(float x1, float y1, float x2, float y2){
   return( sqrtf( (x1 - x2) * (x1 - x2) + (y1 - y2) * (y1 - y2)) );
}

__device__ void collision(float *p1x, float *p1y, float *p2x, float *p2y, float angle){
   float m1 = sqrtf(*p1x**p1x + *p1y**p1y);
   float m2 = sqrtf(*p2x**p2x + *p2y**p2y);
   float d1 = atan2f(*p1y, *p1x);
   float d2 = atan2f(*p2y, *p2x);
   float p1newx = m1 * cos(d1 - angle);
   float p1newy = m1 * sin(d1 - angle);
   float p2newx = m2 * cos(d2 - angle);
   float p2newy = m2 * sin(d2 - angle);

   *p1x = cos(angle) * p2newx + cos(angle + 3.14f / 2.0f) * p1newy;
   *p1y = sin(angle) * p2newx + sin(angle + 3.14f / 2.0f) * p1newy;
   *p2x = cos(angle) * p1newx + cos(angle + 3.14f / 2.0f) * p2newy;
   *p2y = sin(angle) * p1newx + sin(angle + 3.14f / 2.0f) * p2newy;
}

__global__ void calcParticlePos(float4 *p){
   int index = threadIdx.x;
   int i;

   /* Collision with the wall */
   if(p[index].x > 1.0f){
      p[index].x = 1.0f;
      p[index].z *= -1.0f;
   }

   if(p[index].x < -1.0f){
      p[index].x = -1.0f;
      p[index].z *= -1.0f;
   }

   if(p[index].y > 1.0f){
      p[index].y = 1.0f;
      p[index].w *= -1.0f;
   }

   if(p[index].y < -1.0f){
      p[index].y = -1.0f;
      p[index].w *= -1.0f;
   }

   /* Collision with each other */
   for(i = 0; i < PARTICLENUM; i++){
      if(i == index) continue; /*Prevent self collision */

      if(distance(p[i].x, p[i].y, p[index].x, p[index].y) < COLLIDEDIST){
         float angle = atan2f(p[i].y - p[index].y, p[i].x - p[index].x);
         collision(&p[i].z, &p[i].w, &p[index].z, &p[index].w, angle);
      }
   }

   p[index].x = p[index].x + p[index].z;
   p[index].y = p[index].y + p[index].w;

}

/* Handle the keyboard */
void keyboard( unsigned char key, int x, int y){
   switch(key){
      case 27:
         free(particles);
         exit(0);
         break;
   }
}

/* Show the show */
void display(){
   float4 *ppos;

   cudaGraphicsMapResources(1, &pointBuff_CUDA, 0);
   cudaGraphicsResourceGetMappedPointer( (void**)&ppos, NULL, pointBuff_CUDA);
   calcParticlePos<<< 1, PARTICLENUM>>>(ppos);
   cudaGraphicsUnmapResources(1, &pointBuff_CUDA, 0);

   glClear(GL_COLOR_BUFFER_BIT);
   glBindBuffer(GL_ARRAY_BUFFER, pointBuff);
   glVertexPointer(2, GL_FLOAT, 0, NULL);
   glDrawArrays(GL_POINTS, 0, PARTICLENUM);
   glutSwapBuffers();
   glutPostRedisplay();
}

/* Init a draw buffer and link it to the CUDA system */
void initOpenGL(){
   int i;

   particles = (float4*)malloc(sizeof(float4) * PARTICLENUM);
   for( i = 0; i < PARTICLENUM; i++){
      /* Postitions */
      particles[i].x = drand48() * 2.0f - 1.0f;
      particles[i].y = drand48() * 2.0f - 1.0f;
      /* Velocity */
      particles[i].z = (drand48() - 0.5f) / 1000.0f;
      particles[i].w = (drand48() - 0.5f) / 1000.0f;
   }

   glGenBuffers(1, &pointBuff);
   glBindBuffer(GL_ARRAY_BUFFER, pointBuff);
   glBufferData(GL_ARRAY_BUFFER, sizeof(float4) * PARTICLENUM,
                particles,
                GL_DYNAMIC_DRAW);
   cudaGraphicsGLRegisterBuffer(&pointBuff_CUDA, pointBuff,
                                cudaGraphicsMapFlagsWriteDiscard);

   glPointSize(5);
   glEnableClientState(GL_VERTEX_ARRAY);
   glColor3f(1.0, 0.0, 0.0);
}

int main(int argc, char **argv){
  
   /* Init cuda with opengl */
   cudaGLSetGLDevice(0);

   /* opegl window creation process */
   glutInit(&argc, argv);
   glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE);
   glutInitWindowSize(WIDTH, HEIGHT);
   glutCreateWindow("Collision test in CUDA");
   glutDisplayFunc(display);
   glutKeyboardFunc(keyboard);

   initOpenGL();

   glutMainLoop();

   return(0);
}

A program GLUT-ot használ és OpenGL 2.0-t. Először közöljük a rendszerrel, hogy OpenGL-t is kívánunk használni. Erre szolgál a cudaGLSetGLDevice. Ismételten figyelmeztetek mindenkit, hogy nem vizsgálom le a visszatérési értékeket! A példaprogramban egy vertex buffert (pointBuff) hozunk létre, ami tárolja az ütköző részecskék koordinátáit. A cudaGraphicsGLRegisterBuffer segítségével létrehozunk egy CUDA azonosítót, és összekapcsoljuk az OpenGL pufferét a CUDA-éval. Erre azért van szükség, mert mindkét erőforrás a grafikus kártyán van, nincs szükség a mozgatására. Az érdekes lépések a display függvényben vannak. Először létrehozunk egy mutatót a pufferünkre (cudaGraphicsResourceGetMappedPointer), majd ezt a mutatót használjuk a kernelben. Mikor végeztünk a munkával, a cudaGraphicsUnmapResource segítségével elérhetővé tesszük a puffert az OpenGL számára.

Az ütközés vizsgálat nem saját találmány, azt a Emanuelle Feronato weboldaláról lestem le. Annyi változtatást eszközöltem, hogy nálam egyenlő súlyúak a pontok, ezért az impulzusok számításánál az ütköző részecskék tömegének arányára nincs szükségem. Aki kedvet érez, végezze el a módosításokat.

Ha valaki kipróbálja a fenti kódot, nagyon meg fog lepődni. Néhány helyen rendben lezajlanak az ütközések, de sok helyen a golyók átsüvítenek egymáson! A programban hiba van. A következő részben a hibakeresést és felderítést fogom bemutatni.

Ahogy egyre fejlettebb és fejlettebb lesz kedvenc 3D API-m, úgy kell egyre újabb és újabb keretrendszert készíteni a demóimnak, hogy lépést tartsak a fejlődéssel.

GNU/Linux alatt az OpenGL és az ablak kezelő rendszer kapcsolatáról a GLX gondoskodik. Ez tekinthető a legalacsonyabb rétegnek. A népszerű, kereszt platformos könyvtárak, mint amilyen az SDL vagy a GLUT, mind erre építenek. Mivel én szeretem, ha minél kevesebb réteg van köztem és az általam programozott eszköz között, ezért nem volt kérdés számomra, hogy meg kell ismernem a GLX használatát.

Az első demó, ami erre épült, a csúfos kudarcomnak tekinthető Aeronautism volt. Itt csak OpenGL 2.0 támogatás volt. Az internetet végigöngészve csak 3.0 és 3.1 keretrendszerre találtam példákat. Vagy feleslegesen elbonyolított, vagy hibáktól hemzsegő verziót találtam, de végül sikerült készítenem egy elég türhető rendszert. Röviden bemutatom:

#define GL_GLEXT_PROTOTYPES
#define GLX_GLXEXT_PROTOTYPES
#include <GL/glx.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
#include <X11/keysym.h>
#include <stdlib.h>
#include <stdio.h>

#define WIDTH 1024
#define HEIGHT 768

Display *display;
Window   window;
XEvent   event;
KeySym   ks;
GLXContext context;

int main(){
   int conf[] = {GLX_DOUBLEBUFFER, True,
                 GLX_DEPTH_SIZE, 12,
                 GLX_RED_SIZE,    4,
                 GLX_BLUE_SIZE,   4,
                 GLX_GREEN_SIZE,  4,
                 GLX_ALPHA_SIZE,  4,
                 None};

   int gl4attr[] = {GLX_CONTEXT_MAJOR_VERSION_ARB, 4, /* OpenGL major version number */
                    GLX_CONTEXT_MINOR_VERSION_ARB, 1, /* OpenGL minor version number */
                    GLX_CONTEXT_FLAGS_ARB,
                    GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB,
                    None};
   GLXFBConfig *fbc;
   int fbcount;
   XSetWindowAttributes swa;
   XVisualInfo *visual;

   int isrunning = 1;

   display = XOpenDisplay(NULL);
   fbc = glXChooseFBConfig(display, DefaultScreen(display), conf, &fbcount);
   visual = glXGetVisualFromFBConfig(display, fbc[0]);
   swa.background_pixel = 0;
   swa.border_pixel     = 0;
   swa.colormap         = XCreateColormap(display, RootWindow(display, visual->screen), visual->visual, AllocNone);
   swa.event_mask       = StructureNotifyMask | ExposureMask | KeyPressMask;
   window = XCreateWindow(display, RootWindow(display, visual->screen), 0, 0, WIDTH, HEIGHT, 0, visual->depth, InputOutput, visual->visual, CWBorderPixel | CWColormap | CWEventMask, &swa);
   context = glXCreateContextAttribsARB(display, fbc[0], NULL, True, gl4attr);
   XMapWindow(display, window);
   glXMakeCurrent(display, window, context);
   free(fbc);
   XFree(visual);

   /* Other OpenGL related initialization stuff here */

   while(isrunning){
      while(XPending(display) > 0){
         XNextEvent(display, &event);
         if(event.type == Expose) break;
         if(event.type == KeyPress){
            ks = XLookupKeysym((XKeyEvent*)&event, 0);
            if(ks == XK_Escape) isrunning = 0;
         }
      }

      /* OpenGL drawing stuff here */

      glXSwapBuffers(display, window);
   }

   /* Free resources */
   glXMakeCurrent(display, 0, 0);
   glXDestroyContext(display, context);
   XDestroyWindow(display, window);
   XCloseDisplay(display);
   return(0);
}

A legújabb OpenGL támogatás kiegészítésként érhető el a GLX rendszerben, ezért a GL_GLEXT_PROTOTYPES és GLX_GLXEXT_PROTOTYPES segítségével definiáljuk, hogy mi használni kívánjuk ezeket a kiegészítéseket. A létre hozni kívánt jellemzőket egészeket tartalmazó tömbként kell átadni, ezek láthatóak a conf és gl4attr változóknál. A tömb végét mindkét esetben egy None jelzi.

Az első komoly műveletet az XOpenDisplay végzi. Kapcsolódik az alapértelmezett X kiszolgálóhoz. Minden további műveletben az itt visszakapott mutatóval dolgozunk. A kapcsolat végén az XCloseDisplay szabadítja fel a lefoglalt erőforrást.

A következő lépésnél két lehetőségünk van, hogy megkapjuk az XVisualInfo-t. Az első, régebbi és ezért szélesebb körben elterjedt módszer, egy GLXPixelmap-en keresztül valósítja meg a kapcsolatot a grafikus kártyával. A függvény a glXChooseVisual. Sokat nem akarok róla írni. Hátránya, hogy a grafikus kártya képét még egyszer leképezi a fizikai memóriában.

Amit itt használunk, az a pixel buffer módszer, ahol közvetlenül érjük el a gpu-t. Hátránya, hogy csak újabb meghajtóprogramokkal érhető el, de mivel a demók többsége modern eszközökön fut, ez nem probléma. A glXChooseFBConfig segítségével kiválasztjuk a megfelelő puffert, ami egyezik az igényeinkkel. Ezeket a conf változóban soroltuk fel. Ha nincs ilyen puffer, a függvény visszatérési értéke NULL.

Általában több puffer is megfelelhet az igényeinknek. Választásunkat a glXGetVisualFromFBConfig függvénnyel jelöljük. Mi most egyszerűen csak az elsőt választjuk, de aki akarja ezen kód alapján kiválaszthatja magának a legjobb XVisualInfot.

XCreateWindow-al elkészítjük az ablakunkat, ahol majd ki akarjuk rajzolni a demót. Ami érdekes számunkra, a GLXContext struktúra. a glXCreateContextAttribsARB kiegészítés segítségével fogjuk elkészíteni OpenGL-es közegünket. Igényeinket a gl4attr tömbbel adjuk át. Amennyiben grafikus kártyánk nem támogatja a megadott OpenGL verziószámot, NULL-t kapunk vissza.

A rendszer minden darabja megvan, már csak össze kell kötni őket. Az XMapWindow elhelyezi az ablakunkat, a glXMakeCurrent pedig összeköti a közeget és az ablakot. Mostantól birtokba vehetjük az OpenGL-t. A példaprogram tartalmaz egy viszonylag primitív billentyű leütés figyelést és a kettős puffereléshez elengedhetetlen lapcserét (glXSwapBuffers).

Amennyiben a felhasználó kilép, a program felszabadítja a lefoglalt erőforrásokat. Már csak egy dologgal vagyok adós, a fordítással:

gcc -lX11 -lGL test.c -o test

Megjegyzés: A program jelenlegi formájában egyetlen visszatérési értéket sem vizsgál, ezért ha hibával tér vissza egy függvény, akkor a program tovább megy és olyan függvénynél áll le, ami látszólag jó. Probléma esetén csökkentsük az OpenGL verziószámot vagy a színeknek fenntartott méretet. Az is előfordulhat, hogy a Mesa az automatikus frissítés során felülírja az NVidia meghajtót, amitől egyetlen GLX alapú program sem fog menni.

Egy orvos 6 évig tanul az egyetemen. Utána két év rezidenskedés vagy 3 év PhD fokozat szerzés következik, Ez akatt az idő alatt megtanulják az emberi szervezet felépítését olyan szinten, hogy a csontokon található apró dudorok nevét is megtanulják latinul. Megismerik a biokémiai hátterét a sejtfolyamatoknak és a gyógyszerek hatásmechanizmusát.

Ennek ellenére az emberek (és itt én is gyakran ebbe a hibába esem) úgy gondolják, hogy mivel az ő testükről van szó, az orvos ebbe nem lehet kompetens. A másik ok vélhetőleg az, hogy egyes orvosok hibákat követnek el, amitől az a téves következtetés él az emberekben, hogy az orvos nem ért semmihez. De vajon tényleg jobban értünk saját testünkhöz?  A következőkben leírok néhány esetet, aminek a fültanúja voltam.

A gyógyszerek mindenhatóságáról eléggé megoszlanak a vélemények. A tömegközlekedésen üldögélve egy néni például azt kifogásolta, hogy akár hányszor elmegy az orvoshoz, az új gyógyszereket ír fel neki. Ezért mikor megkapta őket, az ablaka alatt csipegető madaraknak szórta azokat. A madarak szépen fel is eszegették valamennyit, majd annak rendje és módja szerint fel is fordultak. A néni tudományos alapossággal levonta a következtetést: milyen jó, hogy nem ő ette meg őket.

A másik esetben egy ritka betegségben szenvedő ember kifogásolta, hogy az orvos nem avatja be őt a kezelés döntésmechanizmusába. Ugyanis a beteg elmondása szerint minden szakirodalmat elolvasott, ami az adott betegséggel kapcsolatos. Hozzáteszem, biológiai képzettsége még nálam is rosszabb, tehát eléggé kétségesnek érzem, hogy mit értett meg az angol nyelvű szakirodalomból. (Különösen azok után, hogy elkezdte nekem magyarázni az epigenetikát, mert szerinte én azt nem ismerhetem, az annyira új "valami". Maradjunk annyiban, hogy több volt a hiba a mondandójában, mint a tény.)

A harmadik eset még megdöbbentőbb. Egy idős bácsi betegségéből kifolyólag sok gyógyszert szed. A gyógyszerek egy része a többi gyógyszer mellékhatásait mérsékli. A bonyolult szedési sorok betartásában a bácsi egy közeli ismerőse segít. Eddig nem is lenne baj, de a segítség ennél tovább megy. Történetesen az orvos előírásának enyhe módosításán. Az oka, hogy elolvasták a betegtájékoztatót, ahol az szerepel, hogy hozzászokás esetén növelni kell az adagot. Ezt megakadályozandó, ez a gyógyszer kimarad néha. Az persze senkinek nem tűnik fel, hogy ha rendesen szedik a gyógyszert, a bácsi tünetmentes, de a segítő szándákú módosítások időszakában köhög, légzési nehézségekkel küzd.

Persze nem ilyen fekete és fehér a helyzet. A bácsi is szokott segíteni ismerősének. Mikor annak fájt a lába, a bácsi nyugodtan felajánlotta fájdalomcsillapítóját, amit csak vényre lehetett kapni, de marad még. Az egyetlen probléma, hogy az a fájdalomcsillapító szívfájdalomra volt. Ne tudjuk meg, milyen hatása volt.

Vannak mások, akik saját képességeiket túlértékelik. Ők úgy gondolják, hogy a valóság megegyezik a TV sorozatokban bemutatott világgal, tehát a gyógyítás érdekében az ott leírtakat kell alkalmazni. Tehát ha valaki a Dr. House-t nézi, azt gondolja, hogy a gyógyítás egyfajta nyomozó munka. Például volt egy ismerősöm, aki vesegörcsökkel küzdött, sokat járt orvoshoz. Főnöke erre leszúrta, hogy miért nem maga próbálja meg meggyógyítani magát, hiszen csak meg kell keresni a kiváltó okot. A főnök példát is adott. Mikor lázas volt, sokat böfögött. Empirikusan kiderítette, hogy ennek oka a megnövekedett nyálelválasztása volt, amit le kellett nyelnie. A nyeléssel jelentős mennyiségű levegő is a gyomrába jutott, aminek ugye valahol távoznia kellett. Tehát, ha valaki kitalálja mitől böfög, az a vesebetegséget is gyógyítani tudja.

A lényeg, hogy gondoljuk végig: mi mit szólnánk hozzá, ha egy nem szakmabeli felülbírálná a döntesünket szakmai kérdésben? Nem kérdeznénk meg tőle, hogy akkor miért nem csinálja maga?

A mai nap érdekes felfedezést tettem. A csapatom neve egy dalban is megtalálható:

A dalszöveget nem tudom ki írta az oldalra, de a youtube verziót meghallgatva sokkal inkább ezt lehet érteni:

"..cybernetic genetics genetic replenish with scars on the tendings.."

Ráadásul ennek még értelme is van.

Nyilván mindenki túl van a teljes dokumentáció átolvasásán, a példaprogramok végignézésén és talán már 5-6 programot is írtak hiba nélkül. Én nem tartozom közéjük. A példáprogramokat megnéztem. Különösen sok időt töltöttem el egy füst animációt bemutató programnál.

A dokumentációban leírtakat nem akarom megismételni. Nézzünk néhány teljesítmény mutatót. A CUDA magok sebességéről is elég sok tesztet lehet látni, ezért inkább a memória használatot mutatnám be.

A tesztprogramunk a következő:

 #include <stdio.h> #define SIZE 3000

int main(int argc, char **argv){
   float *gpustuff;
   cudaError_t error;
   int i;

   printf("Memoria foglalas GPU\n");

   for(i = 0; i < SIZE * 6; i++){

      error = cudaMalloc(&gpustuff, SIZE * sizeof(float));
      if(error != cudaSuccess){
         printf("Hiba %s\n", cudaGetErrorString(error));
         return(-1);
      }

      error = cudaFree(gpustuff);

      if(error != cudaSuccess){
         printf("Hiba %s\n", cudaGetErrorString(error));
         return(-1);
      }

   }

   printf("Minden rendben\n");
   return(0);
}

A teszt program egy Intel Celeron D 320-on 1 GB ram(kéretik nem hangosan felnevetni) Nvidia Quadro 600. Mivel tartottam attól, hogy a CUDA környezet inicializálása sok időt vesz igénybe, ami torzíthatja a mérést, ezért a programot többször futtattam a for ciklus méretének változtatásával. A CPU verziót nem közlöm, azt mindenki írja meg maga :-) A táblázat első oszlopa azt mutatja, hányszor futott le a for ciklus. A második oszlop a Linuxos time paranccsal mennyi időt mértem. A harmadik oszlop a CPU verzió ideje, szintén time paranccsal.

3000 1.159 0.005
6000 2.090 0.004
9000 3.215 0.004
12000 4.032 0.005
15000 6.793 0.005
18000 6.819 0.004

Ugyan ez a teszt egy másik gépen (AMD Athlon X2 4400, 4GB ram, Nvidia Geforce 8500) a következő eredményt adta:

3000 0.970 0.003
6000 1.875 0.003
9000 2.770 0.003
12000 3.688 0.002
15000 4.588 0.004
18000 5.506 0.004

Tehát a memória foglalás rendkívül költséges művelet.

Nem minden nap esik meg az emberrel, hogy a munkája és a hobbija keresztezi egymást. Legalábbis két olyan távoli terület esetében, mint a demoscene és a biológia. Most viszont bekövetkezett a lehetetlen, GPU gyorsított bioinformatikai algoritmusokat kell készítenem. A feladatot értelemszerűen nem fogom bemutatni, de néhány általános érvényű, hasznos tudást megpróbálok megosztani az olvasókkal. Az itt megszerzett tudást remélem nem csak a munkám során, de a demók készítésénél is felhasználhatom.

A CUDA programozást én GNU/Linux (Slackware 13 64bit) rendszer alatt fogom végezni, ami valószínűleg több fejfájást fog okozni, mintha ugyan ezt Microsoft Windows alatt tenném. A videókártya egy Geforce 8500 GT. A cikk írásának idején sem volt a legújabb. Az elvek megismeréséhez viszont elég lesz.

Kezdjük is mindjárt a telepítéssel. Telepítettem a 260.19.26 jelű 64 bites NVidia meghajtóprogramot, abból is a "devdriver" jelűt. Aki használt már Linuxot és a fenti gyártó meghajtóprogramját, annak nem lesz nehézsége a telepítéssel. Aki még nem csinált ilyet, annak gyorsan leírom, mit kell tennie: Kilépni az X-ből, futási jogot adni a letöltött fájlnak, majd elindítani. Ha valaki nem Slackware-t használ, szüksége lehet a kernel fejlécállományokra.

A második lépést a programozói környezet (SDK) telepítése. Ez a CUDA Toolkit 3.2.16 64 bites verzió. Mivel a Slackware nem támogatott, ezért a Fedorás csomagot töltöttem le. Gyakorlatilag csak kibont egy tömörített állományt a megadott könyvtárba, esetemben az /usr/local/cuda-ba. Be kell állítani az elérési útba az /usr/local/cuda/bin-t (én az /etc/profiles.d/cuda.sh fájlt hoztam létre, beleírtam, hogy PATH="$PATH:/usr/local/cuda/bin"). Ha nem akarjuk újraindítani a gépet, akkor futtassuk a következő módon a cuda.sh-t:: . cuda.sh. A pont után hagyjunk szünetet! Ez a soruce-olás, amire nem tudok megfelelő magyar szót.

A programozói könyvtárak használatához pedig szerkeszteni kell az /etc/ld.so.conf állományt. Felvettem az /usr/local/cuda/lib64 sort, majd szerkesztés után rendszergazdai jogokkal futtassuk az ldconfig-t.

Az /usr/local/cuda/doc könyvtár rengeteg hasznos dokumentációt tartalmaz PDF formátumban. Egy kezdő programozónak viszont példaprogramokra van szüksége. Szerencsére ezeket is be lehet szerezni az NVidia oldaláról. Ez a korábbiakban megismert módon telepíthető. A felhasználó könyvtárába kitömöríti az állomány tartalmát.

Fordítsuk le a példákat! Lépjünk be a példák könyvtárának C alkönyvtárába és adjuk ki a make parancsot. Egy kis ideig eltart, mire a példák lefordulnak. Ha a fenti lépések hibátlanok, akkor a fordítás során csak figyelmeztetések tömkelegét kapjuk. Nézegessük a példákat, én is ezt fogom tenni.

Kiegészítés:

Mivel technikailag ide illik, ezért leírom, hogy a fenti folyamatot Fedora 14 alatt is végigjátszottam. Mint is mondjak? Nagyon más a telepítés menete. Először is, a Fedora tartalmaz egy nouveau kernel modult, ami megfigyeléseim szerint egy igen alacsony szintű képernyő meghajtó. Gyakorlatilag az initrd betöltése óta ott figyel a memóriában és minden képernyő kezeléssel kapcsolatos feladatot átvesz. Még a framebuffer vezérléséből is kiveszi a részét.

Ezért a telepítési lépéseket úgy kell kezdeni, hogy átírjuk a grub.conf-ot a /boot/grub könyvtárban. A kernel sor végére a következőt kell írni: rdblacklist=nouveau nouveau.modeset=0. Ez megakadályozza a kernel modul betöltését. A másik lépés, hogy az /etc/inittab fájlba a legutolsó sort (id:5:initdefault:) az 5-öst 3-asra átírjuk. Ennek célja, hogy megakadályozzuk a Fedorát, hogy elindítsa az X kiszolgálót. Indítsuk újra a rendszert. Csodáljuk meg a puritán bejelentkező képernyőt, majd lépjünk be root-ként és hajtsuk végre a fent leírtakat. Miután végeztünk, ne felejtsük el az /etc/inittab-ot 5-re visszaírni.

Nagymamám épp süteményeket csomagolta nekem, hogy hazaérve is élvezhessem azt az egyedülálló ízvilágot, ami csak az ő édességeire volt jellemző. Bármilyen ételt is készített, annak mindig ugyan olyan íze volt. Sokszor gondolkodtam rajta, vajon miként képes ellensúlyozni az alapanyagok folyton változó minőségét.

Nagypapám szótlanul ült ugyan azon a széken, ahol mindig is ülni szokott. Görnyedt háttal, némán hintázott a szék első két lábán, mivel lábai csak úgy érték el a földet, ha kicsit megbillentette a széket. A hosszú idő alatt kis rovátkákat vágott a PVC padlóba és redőket nagymamám homlokára eme mutatványával. De nem most. Most a csomagolás volt a legfontosabb.

A süteményeket néztem. Eszembe sem jutottak sem feleségem, sem gyerekeim és én abban a pillanatban nem is csodálkoztam ezen, holott máskor minden gondolatom körülöttük forgott. Most viszont mindennek a középpontjában én voltam, mintha újra gyerek lennék, akinek más dolga sincs, mint magába szívja azt a sok szeretetet és gondoskodást, ami feléje áramlik. Egy ember, bármennyi idős is legyen, csak a nagyszülei mellett lehet teljesen gyerek. A szülők, akiknek nap, mint nap a nevelés nehézségeivel is szembe kell nézniük, nem tudják azt a fajta kényeztetést biztosítani, amit egy nagyszülő.

Ezt a helyzetet magam is megtapasztaltam gyerekként, most átélem felnőttként. Remélem, eljön az idő, amikor nagyszülőként a harmadik oldalt is megismerhetem.

Néztem, ahogy a ráncos kezek hatalmas szeretettel egymáshoz illesztik a kis sütemény darabokat, mintha tészta-téglák lennének. Néztem a gondoskodás megnyilvánulását, majd arra gondoltam, hogy mondhatott olyat a húgom, hogy Mama meghalt. Otromba tréfa volt. A legrosszabb, hogy másoknak is tovább adtam ezt a képtelenséget, akik ha rájönnek hazugságomra, ugyan olyan mérgesek lesznek rám, mint ahogy én a testvéremre.

- Csomagolok almát is - mondta Mama. Én nem viszakoztam. Még az illendőség is megkívánta volna, hogy legalább a látszat kedvéért elhárítsam a kedvességet és belebonyolódjunk egy olyan vitába, aminek a végeredménye úgyis az, hogy elhozom az almákat is. Nem tettem. Álltam mosolyogva, mint egy ünnepelt királyfi, akit nem győznek elhalmozni ajándékokkal.

Tökéletes pillanat volt minden szempontból. Mindenki boldog volt és örült. Úgy éreztem, hogy ez a sok kedvesség, mint egy öngerjesztő folyamat, elér egy pontot, és valami olyat teszek, amit nem szoktam. Ugrálni kezdek, megölelem nagyszüleimet, ostobán vihogok, mint egy öt éves, aki nem tudja türtőztetni magát.

Az óra hangja irreálisnak tűnt ebben a pillanatban. Irreálisnak, mégis ez volt az egyetlen valóságos elem, de ezt csak akkor értettem meg, amikor kinyitottam a szemem. Megpillantottam a mennyezetet és azonnal tudtam, hogy nincs alma, nem várnak sütemények és senki nem fog kényeztetni, mert nagyszüleim sincsenek. Húgom igazat mondott. Az eszem mindig is tudta ezt, de érzékeim számára a valóság attól függ, hogy nyitva van-e a szemem vagy csukva.

Kikapcsoltam az órát és kikeltem az ágyból. A halottak pedig nyugodjanak békében.

A mai nap egy újabb hiányos dokumentációjú, rendkívül bonyolult programmal, vagy inkább program családdal fogunk megismerkedni. A Broad Institute GATK2 programjával, annak is a genetikai variációk felderítésére szolgáló folyamatával.

Az új generációs szekvenálási eljárások következtében ugyanis rá kellett jönnünk, hogy a genetikai változékonyság korábban nem sejtett módokon is felbukkanhat. Ezek feltérképezése nem egyszerű feladat, mert akár ki akármit is mond, ezek a szekvenálási eljárások sok hibát ejtenek. Elég csak arra gondolni, hogy a megkapott szekvenciák fele nem téképeződik a referencia genomra. Tehát van egy csomó, hibáktól hemzsegő adatsorunk, amit hozzá kell illeszteni egy szabványnak kikiáltott szekvenciához és ráadásul meg is kell mondanunk, hogy mi a hiba, és mi az, ami csak az egyéni különbségekből adódó eltérés.

Erre számtalan program van, abból most nézzük meg a GATK2-t. A program telepítése meglehetősen egyszerű. A mi esetünkben két Javas JAR fájlra lesz szükség: AnalyzeCovariates.jar és GenomeAnalysisTK.jar. Ezen felül a jól ismert SamTools programcsomag is kell, vagy annak Javasított változata a Picard. Ezek telepítésére nem térek ki, elég egyszerűek, probléma nincs velük. Szükséges továbbá egy térképező program, ami a short read-eket a referencia genomon elhelyezi. Fontos, hogy a program BAM outputot generáljon (ezt a SAM kimenetből egy paranccsal könnyen átalakíthatjuk BAM-á), mert a GATK2 csak ezt hajlandó megenni. (Mint látni fogjuk, elég kényes a gyomra.)

A folyamat elrettentésül itt látható. Ezt, és a dokumentációt követve a következő kiegészítéseket teszem:

• A referencia faj szekvenciája .fasta kiterjesztésű legyen. Természetesen a formátuma is, de az .fna kiterjesztés esetén a program megáll.
• A létező variációkat tartalmazó fájl .rod-ra végződjön.
• A dupikációk kezelése előtt rendezzük a BAM állományt koordináták szerint növekvő módon.
• Minden egyes lépés kéri, hogy a BAM állomány tartalmazzon egy úgynevezett read groupot. A GenomeAnalysisTK.jar tartalmaz opciót, amivel megadhatunk neki alapértelmezett nevet (--default_read_group), de a későbbi programoknál ez hiányzik. Jobb mindjárt az elején a fejlécben elhelyezni ezt, és minden egyes sorban szintén kell a read group tag.
• A szekvenáló platform nevét is meg kell adni. Itt is van opció rá, ugyan csak a lépés elején használt programnál (--default_platform). Később nincs.
• A TableRecalibration lépésnél nincs -outputBam. Helyett --out opciót kell használni.
• Használjuk nyugodtan a -U ALLOW_UNINDEXED_BAM opciót. Sok kényelmetlenségtől kíméljük meg magunkat. (Vagy indexeljük BAM állományunkat)

Sok mappelő program nem készít korrekt SAM állományt. Ezt mindig ellenőrizzük, mert a program nagyon nem szereti a nem szabványos, illetve hiányos állományt. A leggyakoribb hiány a ReadGroup (@RG) mind a fejlécben, mint az egyes sorok végén.

Munkám során eddig egy érdekes jelenséget tapasztaltam, mégpedig azt, hogy az összes variáció guanin vagy citozin. Még nem tudom megmagyarázni, hogy mi a hiba oka, de ha megtaláltam, majd beszámolok róla itt.

A programcsomag Windows alatt furcsa jelenséget produkál. Minden alkalommal, amikor olvas a referencia fájlból, létrehoz egy fai kiterjesztésű állományt, ha még nem létezne. Windows alatt viszont valószínű egy Java szál fogva tartja ezt a fájlt és amint egy másik folyamat írni akar bele, azonnal elszáll.

Történt, hogy szükségem volt több gigányi bioinformatikai anyagra egy szerveren, amit nem volt könnyű megközelíteni. Először is csak bizonyos tartományokról lehetett kapcsolódni hozzá, de ez volt a kisebb baj. A nagyobb probléma az volt, hogy a célszerver (legyen a neve storage), csak két másik szerveren keresztül volt elérhető. (Legyen a nevük gate és barrier)

A belépés valami ilyesmi volt:

local> ssh gate

gate> ssh barrier

barrier> ssh storage

Ez igen kellemetlen, ha adatokat akarok lementeni róla, hiszen sok scp lépésre van szükség. Arról nem is beszélve, hogy sem a gate, sem a barrier nem tartalmaz annyi tárhelyet, hogy átmenetileg ott tároljam az adatokat. Szükség lenne egy olyan lépésre, ami segítségével egyből elérhetném a storage-t.

Itt jönnek képbe az ssh alagutak. Nem vagyok nagy szakértő, én is innen tanultam meg a lépéseket. Viszont itt egyszerűbb eset volt vázolva, mint amire nekem szükségem lett volna. Ha két gépen is át kell menni, akkor a következő konfigurációs állomány jöhet szóba:

Host gate
HostName gate.ize.com
User Travis
LocalForward 22000 barrier.ize.com:22
Host barrier
HostName localhost
User Travis
Port 22000
LocalForward 22001 storage.ize.com:22
Host storage
HostName localhost
User Travis
Port 22001

Ennyi. A kapcsolódás is módosul kissé:

localhost> ssh -N -f -q gate

localhost> ssh -N -f -q barrier

localhost> ssh storage

Bent vagyunk! Az utolsó ssh-t scp-re is cserélhetjük, és már másolhatjuk is az adatokat.

Mai alkalommal az UTGB-t veszem górcső alá. A program minden Java fejlesztő álma lehet, mert Mavent, Tomcatet is használ. A honlap szerint képes leszek pár perc alatt genom böngészőt varázsolni a gépemre. A korábbi bejegyzésem az EnsEMBL-től megmutatja, hogy ott a telepítés igencsak fájdalmas és hosszadalmas lehet. Nézzük, mire is képes ez a kis program.

A telepítésnél lehetőség van egy klikkeléssel a gépünkre rakni Java Web Starttal. Mivel én felhőre akarok telepíteni, csak a manuális munka jöhet szóba. Pedig milyen jó lenne, ha egy klikkeléssel megcsinálná helyettem! :-)

Komolyra fordítva a szót: Le kell tölteni egy zip fájlt, és a dokumentáció szerint eljárni. Valóban gyorsan és egyszerűen lehet telepíteni. Az első projekt létrehozása sem bonyolultabb, mint GWT-ben. Elkészül egy könyvtárstruktúra. Ebbe bele kell lépni a további műveletek végett. Az első fordítás viszont a Mavennek hála letölt egy csomó Javas csomagot. Ez persze nem baj. Bizonyára mások sem szeretnek a különböző függőségekkel bajlódni. Fordítás után elindítjuk a szervert, mire az utgb még több csomag letöltésébe kezd. Végül elindul, és a portable Tomcat nem válaszol. Ezen nem is kell csodálkozni, rendbe kell hozni.

Igen, az Amazonos gép portja nem volt nyitva. Miután korrigáltam, szépen meg is jelenik a teszt oldal. Mivel Java-s alkalmazásról van szó, nem csoda, hogy Eclipse nélkül nem lehet birizgálni a forráskódot. Legalábbis a készítők szerint. Az Amazonos virtuális gépen nincs X, ezért ez számomra nem opció. Nincs is rá szükség. A lényeg az src könyvtárban található.

Az adatbázis telepítése viszonylag egyszerű volt, ráadásul a rutin is segített. Most viszont egy új kihívással állok szembe. A teljes weboldalt telepíteni akarom egy Amazonos gépre.

Mindjárt az elején közlöm, hogy a dokumentáció nem sokat ér. Sok olyan lépés van, ami vagy hibás, vagy elfelejtették leírni, ezért most röviden összegzem ezeket.

Mindjárt az elején a Perl modulok listája hiányos. Szükség van az

• LWP::Parallel::UserAgent
• JSON
• GD::Text

modulokra is. Ráadásul az előbbi modulnak van egy elavult függősége, csak a tesztelés kihagyásával lehetett feltenni, ami nem egy életbiztosítás.

Az Apache telepítésről szóló rész rossz. A helyes konfigurálási opció: ./configure --enable-deflate --enable-headers --enable-expires --prefix=xxxx

A dokumentáció elfelejti, hogy miután konfiguráltuk, make és make install is kell.

Nem úgy csomagoljuk ki a mod_perl csomagot, hogy tar zxf mod_perl-2.0.3.tar.gz | tar xvf - Ennek semmi értelme.

CVS segítségével nem lehetett leszedni a BioPerl-t, de ezt korábban már telepítettem, ezért nem foglalkoztam vele.

Az Apache és a mod_perl installálását nem bízhatjuk sajnos az apt-get-re Ubuntu alatt, mert olyan beállításokat tartalmaznak, amely miatt az ensEMBL nem fog elindulni. Bizony célszerű kézzel lefordítani. Persze, aki ezt meg tudta oldani, az kommentben nyugodtan leírhatja, hogyan kell.

A sors fintora, hogy miközben eddig eljutottam, észrevettem, hogy nem kapcsolódik a weboldal az adatbázishoz. Az ok egyszerű. Megjelent az legújabb adatbázis, és nekem eggyel régebbi verzióm volt, miközben a weboldal pedig a legújabb. De ez már csak egy ilyen munka.

Frissítés: Közben ráakadtam a neten erre a cikkre. Úgy látszik másoknak is meggyűlt a baja az ensEMBL-el.

A korábban bemutatott EnsEMBL adatbázist akartam kiegészíteni a weboldallal. Ennek érdekében felállítottam egy webszervert. Nagyjából három óra elteltével a logfájlok tele voltak ilyen bejegyzésekkel:

File does not exist: /usr/local/ensembl/htdocs/phpMyAdmin

Minden féle adminisztrációs felületet keresett egy script és próbált behatolni. Már elszoktam attól, hogy az internet igazi háborús övezet. Az Amazon virtuális gépek valószínűleg a figyelem középpontjában vannak, hiszen könnyű végigscannelni a tartományt. Arról nem is beszélve, hogy a virtualizációhoz használt XEN biztonsági hibáit ismerve könnyen térdre kényszeríthetőek a virtuális gépek.

A netes keresések alapján a használt script valószínűleg a DFind lehetett, ami el is küldi a "névjegyét". Az én támadóm már eljutott addig a szintig, hogy ezt a névjegyet módosítsa erre:

w00tw00t.at.blackhats.romanian.anti-sec

Kicsit megtévesztő a cím, mert a bioscope-ban található programok olyan verziójáról lesz benne szó, amit kiadtak GNU liszensz alatt. Már ez a kijelentés is sántít, mert a programok letöltéséhez regisztrálni kell, ami után megkapjuk a jogot, hogy letöltsük az ingyenes programokat. Stallman biztosan hőzöngene miatta.

Tehát a vizsgált programok a diBayes, a MaToGff és a mapreads. A mapreads az új generációs szekvenálások eredményét képes referencia genomhoz illeszteni. A diBayes ebből keresi meg az SNP-ket. Mivel a két program be- illetve kimeneti valami ok folytán nem kompatíbilis, ezért a MaToGff konvertáló segítségével fogom áthidalni ezt a problémát.

Először is meg kell jegyeznem, hogy jelenlegi formájában egyik program sem használható. A diBayes és a mapreads kódja hiányzó fejléc állományok miatt panaszkodik, a MaToGff indító szkriptjei rossz parancsértelmezőt akarnak betölteni. Nem komoly egyik sem, fél óra alatt sikeresen működésre bírtam őket, mert mint ahogy a jelmondatom is hírdeti: "Senki nem csinálja meg helyetted". Aki viszont nincs megáldva programozói vénával, inkább neki se álljon.

A mapreads kimenete inkább egy szűrőnek tekinthető, mint valódi térképező programnak. Gyakorlatilag leválogatja azokat a readeket, melyek megtalálhatóak a referencia szekvencián. Valami hozzávetőleges pozíciót is ad hozzá. Ha fel akarjuk használni ezeket az eredményeket, akkor a MaToGff segítségével át kell alakítanunk a formátumát. A keletkezett GFF validálását nem végeztem el, mert úgyis adtam tovább a diBayesnek, ami gond nélkül elfogadta. A diBayes elméletileg egy SAM formátumot ad eredményül, de az már ránézésre sem szabványos. Több kötelező mező is hiányzik belőle.

Összegzés: Ezeket a programokat senki ne használja. A SHRiMP és a Bowtie sokkal jobb eredményt ad, kevesebb járulékos munkával. Ha majd lehetőségem lesz kipróbálni a Bioscope-ot, akkor arról is írok. Ezekkel viszont semmit nem lehet kezdeni.

FunctionX-re készített demónk címéhez két szó ötvözéseként jutottam. Az első az aeronauta, amit az Arany iránytű olvasásakor ismertem meg (a demóban egy léghajó kisebb viszontagságait ismerhetjük meg). A másik része pedig az autizmusból eredt. Tetszett a szavak összefonódó jellege.

Nemrég azzal töltöttem az időt, hogy a népszerű keresőoldal segítségével a demócsapatunk nevére kerestem. Legnagyobb meglepetésemre ide jutottam. Tehát a szó, amiről én azt hittem, hogy csupán a képzelet szülte, valójában létező terminológia, a léghajó emelkedésének és lebegésének gyakorlása az atmoszférában.