Az élet kódjai

Második nap. Reggel eszembe jutott egy jelenet, amit érdemes lenne belerakni a demóba, ezért nekiláttam kódolni. Sajnos a kódolás annyi időt felemésztett, hogy rendesen össze sem készültem. Normális esetben szoktam enni- és innivalót vinni magammal. Most csak azt ellenőriztem, hogy nálam legyen a pendrive, azon rajta legyen a release és már rohantam is a tömegközlekedésre.

Mondanom sem kell, hogy a reggeli jó ötletet nem sikerült megvalósítani. A kód ezért aktiválás nélkül csücsül a demóban.

Fotó

A fotók nem okoztak nagy katarzist, amibe az is bejátszhatott, hogy az agyam még a demó körül járt.

Előadások

FabLab: Egy enyhén marketingszagú előadást hallottunk egy nagyszerű kezdeményezésről, ahol a lelkes emberek megvalósíthatják álmaikat olyan eszközök segítségével, amelyekre normális esetben nem lenne pénzük. A marketingszag mellett az előadó nagyon fiatalos és laza volt. Minden második szava az volt, hogy ez vagy az "mekkora fles". Egyszer csak ADT beordította: Amiga! Ez kizökkentette az előadót a mondandójából. Meg is jegyezte, hogy ezt nem érti. A közösség bemutatása is hosszúra sikeredett. Nem azért, mert olyan sokan voltak, hanem mert mindenki annyi mindenhez értett. A normális szakmájukon kívül ilyen képességekre derült fény, mint blogger és vizuális marketing.

4k szintetizátorok: Az intrók által használt zene generáló eszközökről esett szó. Az előadó bemutatta röviden saját eszközeit, majd általános tippeket adott, hogyan írjunk saját eszközt. Az előadásnak egy hibája volt: rövid volt. Szívesen halgattam volna még műhelytitkokat, mint amilyen az, hogy a textúra generátor függvényt hogyan használjuk dallamok készítésére.

Zene

A zenék nem voltak rosszak. A zenei stílus is elég változatos volt, nem korlátozódott a drumm and bass-ra. Személyes kedvencem a Take Me volt, ahol a patikon oly ritkán hallható vokál is megjelent. Természetesen voltak kevésbé jólsikerült alkotások is.

Kézi rajz

Csak hat induló volt. Úgy látszik nem túl népszerű a számítógépek világában a kézi rajz. Rajzokról Grass biztosan fog írni a Scene.hu-n, majd belinkelem.

Freestyle

A szabad stílusú rajzok gyengék voltak. Sokan gondolták úgy, hogy a fotón alkalmazott Photoshop elég a freestyle grafikához. Nincs igazuk. De sajnos még ennél is volt rosszabb. Kimerítő cikket szintén Grass fog írni.

Wild

Mivel ide mindent be lehet adni, mindent be is szoktak. Volt egy zenekészítő kütyü, egy LEGO platformra épülő alkotás, amiről megmondom őszintén, hogy nem tudom, mi lehetett és egy remek stop-motion film. A Los Angeles Lamers hozta a tőlük elvárt formát és poénokat.

Intrók

Az intrók érdekesek voltak. Nem mutattak be egyetlen korszakalkotó, világmegváltó release-t, de nekem tetszettek.

Demo

Tíz induló volt, ami ritkaság magyar partin. Sok új csapat indult. Naívan azt hittem, hogy a középmezőnyben fogunk végezni, de nem így történt. A Biopunk utolsó előtti lett. Igaz, hogy sok hibája volt, mint a nem túl részletes textúra, az alacsony poligonszám, realisztikus effektek hiánya, de én jobbra számítottam. De ilyen a parti. Majd meglátjuk, milyen kommenteket kap pouet.net-en.

A programok között megtekintettem egy MorphOS-t, ami egy laptopon futott. Charlie bemutatta az oprendszer minden darabját. Én meg sikeresen szétfagyasztottam. Sajnos ismert bug volt, pedig jó lett volna egy újat felfedezni.

Blalával is beszéltem, aki - talán az elfogyasztott alkohol hatása alatt - váltig állította, hogy van egy másik Travis is a partin. Felkerekedtünk, hogy megkeressük. Egy ideig erősködtem, hogy nincs másik rajtam kívül, majd feladtam. Nagyjából tíz percig kerestünk engem, amikor Blala rám néz és azt mondja: Nem is Travisnek hívják. Ezzel helyre is állt az univerzum rendje.

Spenot Amigás demót készített, aminek külön érdekessége, hogy a forráskód gond nélkül portolható 64 bites Apple gépre. Győzködtem, hogy adja be, de nem tette.

Történt némi dráma is. D-lee, aki egy ideje többet foglalkozik a Forma1-el, mint a demoscenevel, készíttetett a barátnőjével egy videót, amibe mások zenéjét tette bele, azok előzetes megkérdezése nélkül. Nem mutatták be az alkotást, mert több utalás is volt a szerző céges érdekeltségére. Ezt D-lee személyes sértésnek vette.

Összességében jó parti volt, nagyon tetszett. Volt sírás-nevetés egyaránt.

Az első nap nem alakult jól. Nagyon nem. Arra számítottam, hogy szép, nyugodt pénteki napom lesz, ahol senkit nem fog zavarni, ha a munkaidő egy kis szeletét nem munkával, hanem mondjuk egy hiányzó jelenet elkészítésére fordítok. Nem így történt.

Befutott egy sürgő munka, ami miatt úgy tűnt, még túlórázhatok is. Ez meghiusította azt a tervemet, hogy már pénteken kinézek a partira. A munka végeztével aztán úgy gondoltam, talán már a demómmal foglalkozhatom. Nem így történt. A mosógép furcsán viselkedett, amit szintén nem hagyhattam figyelmen kívül. Este még beléptem a munkahelyi szerverre, hogy megnézzem, kell-e valamit segíteni.

Nem kellett. A nap elcsendesedett és végre koncentrálhattam a demóra. Pár jelenet nem volt tökéletes, azokat állítgattam, hogy minden tökéletes legyen. Természetesen találtam új hibákat, amik nem programozási, inkább látványbeli hibák. A poligonok nem úgy álltak, ahogy szerettem volna. A modellek poligonjainak súlyozását kellett volna állítani, amire nem volt idő, ezért kódban gyorsan korrigáltam ezt. Nem szép, de gyors megoldás.

Éjfél után úgy feküdtem le, hogy így már be lehet adni. Nem lesz egy győztes, de vállalható.

A mai nap a de-novo szekvencia összeszerelésről írok egy rövid ismertetőt, nagyon alap szinten, gyakorlati tudnivalókkal.

Mért kell?

Amikor a tudományos-fantasztikus filmeket nézzük, akkor olyan képet festenek a szekvenálásról, mintha az egy könyv olvasása lenne. Elindulunk az elején, eljutunk a végére. Ez elég szemléletes analógia, ezért a továbbiakban is ezzel a hasonlattal fogok élni.

Ez a világon, sehol nincs így. Sajnos egyszerre csak a teljes genomokhoz képest igen rövid szakaszokat tudunk megszekvenálni. Mikor még laborban dolgoztam, akkor ez a hosszúság kb. 400 bázispár volt, utána a szekvenálás minősége folyamatosan romlott. (Témavezetőm előszeretetttel nyomta a kezembe a szekvenciákat, hogy kézzel javítsam ki őket a leolvasott színkódok alapján. Hiába, a PhD-s munkaerő olcsóbb, mint még egyszer szekvenálni :-) ) Ezt Sanger típusú szekvenálásnak hívják. Nagy pontosságú, de lassú.

Tehát a szekvenálás kis darabokat eredményez, a könyves hasonlathoz visszatérve, a könyv lapjait. Az új típusú szekvenálások meggyorsították a szekvenálás menetét, de rövidebb szekvenciákat eredményeztek. (Nem oldalakat kapunk, csak mondatokat). Az egyik szerencsénk, hogy a szekvenciák átfednek. Ez alapján tudjuk őket összerakni. De ahogy egy regényben is előfordulhatnak ismétlődő mondatok, úgy a genomban is. Tehát eldönteni, hogy egy mondat a 100. oldalra, vagy a 231-re illik, nehéz feladat.

Metódusok

A megoldást különféle algoritmusok nyújtják. Az első és legegyszerűbb, keressünk egyező, kisebb darabokat, összeillesztjük és kiterjesztjük a szekvenciát. Ezek a mohó (greedy) algoritmusok. Mohók, mert nem nézik meg, hogy más helyre érdemesebb-e beépíteni a szekvenciát, csak kiválasszák azt, amivel a legnagyobb hosszúságot elérhetik.

A népszerűbbek a de-bruijn gráfon alapulnak. A csomópontok az egyes szekvenciák, az élek pedig a lehetséges kapcsolódások más szekvenciákkal. Az ismétlődő szakaszok (repeatek) esetén a gráf bonyolult formát vehet fel. ( Egyes algoritmusok az ismétlődések mennyiségét az oda helyezhető szekvenciák számából megpróbálja becsülni. Szakszóval a coverage-ből. )

Napjainkban a hibrid összeszerelők adják a legjobb eredményt. Két vagy több technológián alapuló szekvencia készletből szerelik össze a végső genomot. Például egy hosszabb, de pontatlanabb (szakzsargonnal 454) és egy rövidebb, de pontosabb (Illumina) szekvenálás eredményét ötvözik.

Alkalmazások

Az utóbbi időben kipróbáltam pár de-novo programot, ezek eredményéről fogok beszámolni. Egy bakteriális genomot kellett összeszerelnem, a szekvenciák 454-ből származtak.

1. SOAPDenovo: A kínai intézet szuperfegyvere. Elvileg ezzel rakták össze az óriáspanda genomját. Azért elvileg, mert nekem nem sikerült működésre bírni. A bináris állomány floating point exception-t adott, de még azt sem sikerült kitalálnom, hogy melyik modulban. Nagy csalódás volt.

2. Velvet: A Velvet szimpatikus kis program. Forrásból pillanatok alatt fordítható. Kevés paramétert lehet állítani benne, abból is a legfontosabb a k-mer, ami azt mondja meg, hogy milyen hosszú átfedő darabokat keressen a szekvenciákban. Ha 31-nél nagyobb k-mert szeretnénk használni, akkor újra kell forgatni a programot. Kezeli a color-space szekvenciákat (van egy szekvenálási típus, ahol nem a gimiben megismert ATGC bázisokat kapjuk vissza, hanem egy színkódolt szekvenciát. A kódolásnak gyakorlati haszna van, de néha megkeseríti a bioinformatikusok sorsát) Ismeri a paired-end és mate-pair szekvenciákat is. Két programból áll. Az első készít egy keresőtáblát (velveth), a második pedig megpróbálja megoldani a gráfot (velvetg). A színkódolt szekvenciák esetén szükség van a szekvenciák elő- és utókezelésére. 263 contigot rakott össze nekem.

3. CLC Genomic Workbench: Aki utálja a parancsok gépelgetését, annak itt a klikkelős mindenes. Pénzes program, de 14 napig élvezhetjük a használatát. Van benne egy de-novo modul, ami szerintem egy mohó algoritmuson alapul, legalábbis a paraméterek alapján erre következtetek. Gyakorlatilag bármit beadhatunk neki. Nekem 89 contigot eredményezett a fenti adatsorra. De azt is csináltam, hogy különböző szekvenálásokból a contigokat egybe ömlesztettem, és azzal is tudott mit kezdeni (kevesebbet csinált belőlük). Ezt persze nem javaslom, mert az egyik paramétere, hogy mekkora átfedő szakaszokat vizsgáljon, és itt az átfedő és a teljes szekvencia hosszának arányát várja. Ha tehát különböző hosszúságú szekvenciákat akarunk összerakni vele, akkor a beállításokkal kizárhatjuk egyik vagy másik szekvencia típust. A CLC kezeli az összes szekvenálási technológiát.

3. Mira: Ez a program a legbonyolultabb az összes közül. Rengeteg paramétere van, a bemeneti és kimeneti fájlokra névkonvenció. Viszont ha beállítottuk, akkor elindul és megcsinál mindent. Számol statisztikát, többféle kimenetet produkál, képes hibrid üzemmódra. Alapértelmezett beállításokkal is 36 contigot rakott össze. Cserébe sokáig fut. Nem kezeli a színkódolt szekvenciákat.

Melyik a legjobb

Annak eldöntésére, hogy melyik eredményt hihetjük el, sok paraméter dönt. Az első, hogy hány darabot tud a szekvenciákból összeilleszteni. Értelemszerűen minél többet épít össze minél kevesebb kontigba, annál jobb. A kontigok átlagos hossza is hasznos mérőszám. Van egy N50 (egyes esetekben N25 is) nevű jelzőszám is, ami azon kontigok közül, amelyek az összes kontig teljes hosszának a felét teszik ki, mekkora a legkisebb mérete. Más szóval a legkisebb hosszú kontignak a mérete.

Az idei Functionon a kiírás szerint a Linuxos compogép egy 64bites Ubuntu 11.04 lesz. Én elsősorban Slacware 11 alatt fejlesztek, amit jó ideje nem frissítettem. Tavalyról maradt egy 32 bites Ubuntu 10.04 az egyik partíciómon ezért egy hirtelen ötlettől vezérelve feltelepítettem rá egy Ubuntu 11.04-t.

Nem számítottam semmi problémára, és itt követtem el az első hibát. Az új rendszer felajánlotta a frissítés lehetőségét, de arra gondoltam, jobb lesz, ha egy teljesen szűz rendszeren tesztelem le a demót, ezért a telepítőnek azt mondtam, törölje a régi Ubuntut.

A telepítő engedelmeskedett a parancsnak, és szó nélkül felülírta az első merevlemez MBR-jét is, amit nem akartam. Csak hogy érzékeltessem a káoszt: Van két vinyóm szoftveres RAID-be kötve, ezen van a Slackware és a munkám nagy része. Egy külön vinyón az Ubuntu és még egy vinyó a Windowsnak. A Windowsos MBR-ben van egy LILO, ami be tudja tölteni a Slackware-t és a Windowst, de az Ubuntut nem (sokat próbálkoztam vele, de nem sikerült megoldani). Ezért az Ubuntu MBR-jében vagy egy GRUB, ami szintén be tudja tölteni a Windows-t és az Ubuntut. A Slackware-t nem, pedig ezen is próbálkoztam öt percig, azután nem sikerült és meg nem erőltettem tovább.

Az új Ubuntu minden kérdés nélkül felülírta a Windows-os MBR-t és elvágta a lehetőséget, hogy betöltsem a Slackware-t. Nem baj, úgyis időszerű volt, hogy ne a Bios-ból állítsam be az operációs rendszereket. Gondoltam, majd beírom a megfelelő bejegyzéseket a menu.lst-ba és máris minden rendszert el fogok tudni érni.

Először is, nem találtam meg a start menüt! Az új Unity teljesen idegen volt számomra. A startmenüben csak nehezen találtam meg a terminált. Úgy éreztem magam, mint aki most kapcsolja be először a számítógépet. A terminál már ismerős volt. Csak az ablak menüit nem találtam. Á, hogy a képernyő tetején van, mint a Mac-eknél? Ott sem szeretem ezt a megoldást.

Szerencsére a könyvtár struktúra változatlan maradt. A /boot/grub még mindig a régi. Illetve nem egészen. A grub könyvtár tele van fájlokkal. Azt észrevettem, hogy ezek modulok különböző fájlrendszerekhez. Ez még nem is tűnt rossz ötletnek, hiszen korábban bele kellett pakolni az fstab-ba azokat a partíciókat, is, amelyeket be akarta tölteni az ember, de használni nem akarta. Talán most ennek vége. Kerestem egy menu.lst-t, de nem találtam. Viszont volt grub.cfg. Az is jó nekem. Átírom és minden jó lesz.

Mikor megláttam a felépítését, akkor már tudtam, ezt én bizony át nem írom. Ennél már csak egy XML lehetett volna bonyolultabb. Kénytelen vagyok elhasználni egy segítséget. A közönség szóba sem jöhetett, ha megfelezek valamit, akkor az a számítógép lesz, de baltával, ezért maradt a gugli.

Az okos grub2 zsenik a neten szintén azt javasolták, hogy ne szerkesszem a grub.cfg-t, hanem helyette shell scripteket írogassak, amelyek majd szerkesztik helyettem az állományt, és azt is el kell felejtenem, hogy csak szerkesztem a fájlokat és újraindítok, hanem a LILO-hoz hasonlóan egy paranccsal kell frissíteni a grub-ot. Már csak egy kérdés maradt, mit kezdjek a raid-el?

Abban biztos voltam, hogy kell egy raid modul: insmod raid Ez egyszerű. De mi lesz az eszköz neve? A set root= után mit írjak. A neten csak úgy pongyolán az egyenlőség jel után beírták az eszköz nevét, de az én állományomban egyszeres idézőjelek között szerepeltek az eszköznevek. Úgy döntöttem, ezt használom. A net szerint csak simán md0-val hivatkozhatok az eszközre, de ez sem igaz, legalábbis nálam. No such disk hibaüzenetet kaptam.

Most mit csináljak? Ráadásul utáltam a sok újraindítást is. Szerencsére a grub konzolját megtartották, ezért úgy döntöttem a konzolból próbálgatom az eszközneveket a jó öreg TAB-os kiegészítésekkel. Talán lesz valami.

Ez bejött. Az eszköz valami csoda folytán hd2, msdos1 Igazából nem meglepő, mert annak idején a raid boot partícióját úgy állítottam be, hogy csak tükrözve legyen és az adattároló partíciót állítottam raid1-be. Működött! De mennyi idő elment rá! Ebből is látszik, hogy nem értek a Linuxhoz.

Ui: Kipróbáltam a demót. Szaggatott, mint a fene. Ezért be kellett kapcsolni a driverben a Sync to VBlank opciót, és onnantól szép simán ment. De nem kell neki egyetlen más letöltés sem. Ennek azért örültem.

Organikus térhálókat élethűbbé tehetünk apró, periodikus mozgásokkal. Ilyen
volt például az Aeronautism című demónkban a repülő szörny, aminek a csápjai
és a farokúszója ritmikusan lengett.

A vertex shaderek elsősorban a térhálók csúcsponti koordinátáit és a normál
vektorokat kapják bemenetnek, de a programozó bizonyos számú saját attribútumot
is megadhat. Ezt fogjuk mi is használni, hogy kijelöljük azokat a csúcspontokat,
amelyeket mozgatni akarunk.

A csúcspontok kijelöléséhez kezdetben azt a trükköt használtam, hogy a betöltöttem a modellt egy szerkesztő programba és azokat a csúcsokat, amelyeket nem kívántam mozgatni, kitöröltem. Exportáltam OBJ formátumba a csonka modellt, majd a Linux parancssor és Perl scriptek segítségével összehasonlítottam az eredeti modellel. Végül a különbségükből készítettem egy fájlt, ami minden egyes csúcspontra tartalmazott egy 0 vagy 1 értéket, attól függően, hogy akartam-e mozgatni az adott csúcsot vagy nem. Az Aeronautism-ban volt egy 0.5 is, mert a csápokat máshogy mozgattam, mint a farokúszót.

Szerencsére Blender segítségével egyszerűsíthető a folyamat. Ezt fogom részletezni.

Indítsuk el a Blendert, töltsük be a modellünket. Váltsunk Vertex Paint módba, majd fessük be a kívánt színűre a csúcspontokat. A be nem festett részek fehérek lesznek. Ha többféle mozgást akarunk, akkor használjunk különböző színeket. Ebben a példában pirosat használtam. A mozgások finomhangolására használhatjuk a színek intenzitását is, amit a Paint fülön állíthatunk be.

Ha elküszültünk, akkor egy Python script segítségével könnyedén exportálhatjuk a csúcspontok színeit. A szkript forráskódja a következő:

#!BPY
"""
Name: 'Vertex Color Extract'
Blender: 243
Group: 'Export'
"""
import bpy
import Blender
from Blender import *

scene = bpy.data.scenes.active
for o in scene.objects:
        if o.type == 'Mesh':
                mesh = o
bf = open("vertexcolor.txt", "w")

for face in mesh.data.faces:
        for i, vert in enumerate(face):
                bf.write("%f %f %f %d\n" % (face.col[i].r, face.col[i].g, face.col[i].b, vert.index))
bf.close()
A szkriptet másoljuk a .blender/scripts könyvtárba. Ha már fut a Blender, a Script -> Update Menu menüponttal frissítsünk. Ez a szkript egy nyers adatot ad vissza egy előre definiált fájlba. Minden egyes poligon csúcspontjának a színét és a csúcspont sorszámát adja vissza. Mivel a poligonok közös csúcspontot adnak vissza, ezért az eredmény fájl redundáns. Még mindig nem értek eléggé a Python nyelvhez, ezért az ismétlődő szakaszokat a parancssor segítségével távolítom el:
sort -nk 4 vertexcolor.txt | uniq >eredmeny.txtMinden egyes csúcspont színe megvan. A demónkba töltsük be ezt a fájlt és tároljuk le egy tömbbe. A példában ez a tömb az attrib nevet kapja.
   GLfloat attrib[4432]; /* Tudom, mennyi csúcspontom van a térhálóban */

   file = fopen("vertexcolor.txt", "r");
   while(fgets(line, 200, file) != NULL){
      r = atof(strtok(line, " "));
      g = atof(strtok(NULL, " "));
      b = atof(strtok(NULL, " "));
      index = atoi(strtok(NULL, " \n"));
      if(g == 0.0 && b == 0.0){
         attrib[index] = 1.0;
      }
      else{
         attrib[index] = 0.0;
      }
   }
   fclose(file);
A példaprogram elég egyszerű. Mivel egy demóban a programozó tudja, hogy az adott modell mennyi csúcspontból áll, ezért bocsánatos bűn, ha ezt beégetem a kódba. Ha újra akarjuk használni a kódot, akkor természetesen át kell tervezni azt.

Miután beolvastuk a fájlból az adatokat, készítünk egy vertex buffert a tárolására:
   glGenBuffers(1, &vbo);
   glBindBuffer(GL_ARRAY_BUFFER, vbo);
   glBufferData(GL_ARRAY_BUFFER, sizeof(GLfloat) * vertexcount, attrib, GL_STATIC_DRAW);
Majd a shader megfelelő változójához kötjük a vertex buffert. Ez a lépés nagyban hasonlít a korábban bemutatott csúcspont és normál vektornál használt módszerhez.
  glBindVertexArray(vao);
  uni = glGetAttribLocation(shader, "sniff");
  glBindBuffer(GL_ARRAY_BUFFER, vbo);
  glVertexAttribPointer(uni, 1, GL_FLOAT, GL_FALSE, 0, 0);
  glEnableVertexAttribArray(uni);
Az OpenGL kirajzoló rutin a következő képpen fest:

   glUseProgram(shaderprg);
   time = getTimeInterval();
   uni = glGetUniformLocation(snooze, "time");
   glUniform1f(uni, time);
Végezetül lássuk a shader kódot:

#version 410
in vec3 vertex;
in vec3 normal;
in float sniff;

uniform mat4 pmatrix;
uniform mat4 modelmatrix;
uniform float time;

out vec3 color;

void main(void){
   vec3 pos = vertex;

   if(sniff == 1.0) pos.y = pos.y + sin(time * 40.0) / 300.0;

   gl_Position = pmatrix * modelmatrix * vec4(pos, 1.0);
   color = normal * vec3(1.0);
}Amely csúcspontnál az attribútum 1.0, ott a pozíció egy kis színusz függvény segítségével oszcillál, amitől élőbbnek tűnik a háló. Még élethűbb lehet a modell, ha zaj segítségével kiszámíthatatlanabbá tesszük a mozgást. A példafájlban a modellt Grass készítette. A Function-os demónkban is látható lesz. (A program teljes forráskódját hamarosan elérhetővé teszem)
 

A munkahelyemen sajnos én vagyok az, aki észreveszi azokat a hibákat, amelyek felett mások átsiklanak. Ez azért rossz, mert unalmas tesztelési munkákat is kell végeznem. Így történt, hogy egy bioinformatikai program tesztelése során furcsa anomáliára figyeltem fel. A program több szálon futott, számtalan ideiglenes állományt írt és olvasott. Ezalatt felzabált 100GB helyet, majd eredményül visszaadott 2GB-ot.

A hiba nem hagyott nyugodni, ezért megnéztem a forráskódot is. Mivel bioinformatikus vagyok, a programozók általában úgy tekintenek rám, mint valami Szkript Kölyökre, aki csak Perl-ben tud turkálni. Emberhiány esetén adnak programozós feladatot, de az is elég marginális, mintha félnének, hogy összedöntöm a verzió-követő rendszert. A nyár és a szabadságok ideje viszont megnyitotta az utat előttem, hogy megmutassam, mit tudok.

A hibát sikerült visszavezetnem egy fájl másoló metódusra, ahol NIO-t használtak. Emlékeztem is rá egy megbeszélésből, ahol a programozók bőszen magyarázták az előnyeit. A forráskódban viszont találtam egy tutorial kódot. A változók más néven szerepeltek, de egyébként kínos hasonlóságot mutatott ezze. Az egyetlen probléma, hogy a kód csak 2GB alatti fájloknál működik. Korrekt formája ez lenne:

import java.io.*;
import java.nio.channels.FileChannel;

public class niotest {
   public static void main(String[] args){
      File sfile = new File(args[0]);
      File dfile = new File(args[1]);

      try{
         dfile.createNewFile();
      }
      catch(Exception e){
         e.printStackTrace();
      }

      FileChannel from = null;
      FileChannel to   = null;

      try{
         from = new FileInputStream(sfile).getChannel();
         to   = new FileOutputStream(dfile).getChannel();
         System.out.printf("File size: %d\n", from.size());
         long written = 0;
         while(written < from.size()){
            written += to.transferFrom(from, written, from.size() - written);
         }
         System.out.printf("Written: %d\n", written);

         from.close();
         to.close();
      }
      catch(Exception e){
         e.printStackTrace();
      }
   }
}Mert el kell olvasni a dokumentációt is, nem csak kimásolni a kódot.

A 3.1-es verzió óta az OpenGL nem tartalmazza a forgatással, eltolással kapcsolatos rutinokat. A profik azt írják, hogy ez egy jó ötlet volt, mert nem zárja korlátok közé a programozót. Egy API-nak viszont az a feladata, hogy megkönnyítse egy programozó életét. Ha egy alapvető funkcionalitás hiányzik az API-ból, akkor programozók tömegét kényszerítjük arra, hogy ugyan azt a feladatot elkészítse.

Aki nem akar saját maga bajlódni a mátrixok számolásával, az használhatja a glm-et, vagy egy korábbi posztomban említett Nopper úr GLUS könyvtárát. Én viszont egy merészet gondoltam, és úgy döntöttem, megírom saját rutinjaimat. Azért nevezem merésznek az ötletet, mert nem sokat konyítok a matematikához. Igyekeztem faék egyszerűségű kódot írni, amitől lehet, hogy a kód használhatósága nehézkes lesz. A megértést viszont biztosan nem fogja gátolni.

Az első és legfontosabb megemlíteni, hogy az OpenGL oszlopfolytonosan várja a mátrixokat, ami a Wikipédiában fellelhető mátrixok transzponáltja. Érthetően fogalmazva:

0 4 8 12
1 5 9 13
2 6 10 14
3 7 11 15

 Legyenen az indexek. Az általam használt kódban minden mátrix egy 16 elemű tömb lesz.

Egységmátrix

A legalapvetőbb mátrix a 3D grafikában. Az átló mentén 1-t tartalmaz. Erre azért van szükség, mert a mátrixok szorzása alkalmával nem fogja egyik mátrix a másikat kinullázni. Minden további mátrix ebből indul ki, külön nem fogom leírni.

Perspektíva

A perspektíva viszonylag egyszerű. A képernyő oldalaránya és a látószög beállítása mellett kiszámítja a mátrix értékeit. Két további paramétere a közeli és távoli vágási távolság.

void perspectiveMatrix(float *m, float fov, float aspect, float near, float far){
  float range;

  range = tan(fov * M_PI/360.0) * near;
  memset(m, 0, sizeof(float) * 16);
  m[0] = (2.0 * near) / ((range * aspect) - (-range * aspect));
  m[5] = (2.0 * near) / (2.0 * range);
  m[10] = -(far + near) / (far - near);
  m[11] = -1.0;
  m[14] = -(2.0 * far * near) / (far - near);
}


Kamera pozíció

Egy demóban, megkockáztatom ez az egyik legfontosabb mátrix. Segítségével megadhatjuk, hogy honnan nézzük a jelenetet. Ennek megfelelően bonyolult, mert több vektorműveletet kell végezni.

void lookAt(float *m, float *eye, float *target, float *up){
   int i;
   float n[3];
   float u[3];
   float v[3];
   float d[3];

   for(i = 0; i < 3; i++) n[i] = eye[i] - target[i];
   crossproduct3v(up, n, u);
   crossproduct3v(n, u, v);
   normalize(u, 3);
   d[0] = dotproduct(eye, u, 3) * -1.0;
   normalize(v, 3);
   d[1] = dotproduct(eye, v, 3) * -1.0;
   normalize(n, 3);
   d[2] = dotproduct(eye, n, 3) * -1.0;

   m[0]  = u[0];
   m[4]  = u[1];
   m[8]  = u[2];
   m[12] = d[0];
   m[1]  = v[0];
   m[5]  = v[1];
   m[9]  = v[2];
   m[13] = d[1];
   m[2]  = n[0];
   m[6]  = n[1];
   m[10] = n[2];
   m[14] = d[2];
   m[3]  = 0.0;
   m[7]  = 0.0;
   m[11] = 0.0;
   m[15] = 1.0;
}


Pozíció

A pozíció mátrix a legegyszerűbb. Gyakorlatilag a mátrix három elemét helyettesítjük a koordinátákkal.

void translate(float *m, float x, float y, float z){
   int i;

   /* Identity matrix */
   for(i = 0; i < 16; i++){
      if( (i % 5) == 0){
         m[i] = 1.0;
      }
      else m[i] = 0.0;
   }

   m[12] = x;
   m[13] = y;
   m[14] = z;
}


Forgatás

A forgatás néz ki a legijesztőbben. A legtöbb példaprogram külön veszi a tengelyek mentén történő forgatásokat, majd mátrix szorzásokkal egy forgatási mátrixot képez. Szerencsére lehet találni olyan leírást, ami leírja, hogyan néz ki az a mátrix, amiben elvégezték a mátrix szorzást. A kód ilyesztő, de csak egyszer kell megírni.

 void rotate(float *m, float rx, float ry, float rz){
   int i;
   /* Identity matrix */
   for(i = 0; i < 16; i++){
      if( (i % 5) == 0){
         m[i] = 1.0;
      }
      else m[i] = 0.0;
   }

   /* General rotation */
   m[0]  =  cosf(ry) * cosf(rz);
   m[4]  = -cosf(rx) * sinf(rz) + sinf(rx) * sinf(ry) * cosf(rz);
   m[8]  =  sinf(rx) * sinf(rz) + cosf(rx) * sinf(ry) * cosf(rz);
   m[12] =  0.0;
   m[1]  =  cosf(ry) * sinf(rz);
   m[5]  =  cosf(rx) * cosf(rz) + sinf(rx) * sinf(ry) * sinf(rz);
   m[9]  = -sinf(rx) * cosf(rz) + cosf(rx) * sinf(ry) * sinf(rz);
   m[13] =  0.0;
   m[2]  = -sinf(ry);
   m[6]  =  sinf(rx) * cosf(ry);
   m[10] =  cosf(rx) * cosf(ry);
   m[14] =  0.0;
   m[3]  =  0.0;
   m[7]  =  0.0;
   m[11] =  0.0;
   m[15] =  1.0;

}


Egyéb mátrix műveletek

Most pedig jöjjenek az egyéb nyalánkságok. A kamera pozíciójánál a kódban ilyen függvények láthatóak, mint crossproduct meg dotproduct. Mik ezek? Az első a vektoriális szorzat, aminek érdekessége, hogy csak 3 dimenzióban értelmezik.

void crossproduct3v(float *a, float *b, float *result){
   result[0] = a[1] * b[2] - a[2] * b[1];
   result[1] = a[2] * b[0] - a[0] * b[2];
   result[2] = a[0] * b[1] - a[1] * b[0];
}


A másik a skaláris szorzat, ami meglepő módon egy számot ad vissza. A hossz arányos a két vektor által bezárt szöggel, ezért a fények programozásánál is sokszor előkerül.
float dotproduct(float *a, float *b, int size){
   int i;
   float result = 0.0;

   for(i = 0; i < size; i++) result += a[i] * b[i];
   return(result);
}
Ha programunkban egy térhálós modellt elhelyezünk, forgatunk, és még a kamerát is mozgatjuk, több mátrixot kapunk, de hogyan készítsünk egy mátrixot? A válasz a mátrix szorzás. A mátrix szorzásnál a tagok sorrendje nem felcserélhető. Ezt mindenki ki is próbálhatja, hogy mi történik, ha a modellnél az eltolási mátrixot szorozza a forgatásival, vagy fordítva.

A szorzás sorrendje a következő: perspektíva * forgatás * eltolás * kamera. A szorzást a következő kód valósítja meg:

void matrixMultiply4x4(float *a, float *b, float *c){
   int i,x,y;

   for(i = 0; i < 16; i++){
      x = i & 12;
      y = i % 4;
      c[i] = a[x + 0] * b[y + 0] +
             a[x + 1] * b[y + 4] +
             a[x + 2] * b[y + 8] +
             a[x + 3] * b[y + 12];
   }
}


Mondtam, hogy egyszerű lesz, mint a faék. Hozzáértők a kommentekben mindenféle optimalizációt küldhetnek.

Mátrix betöltése shaderbe

A shaderben a mátrix uniform mat4 deklarációval szerepel. Kódunkban a glGetUniformLocation(shader, változónév) segítségével megkapjuk az erőforrás leíróját (egy egész szám), majd ezt felhasználva a glUniformMatrix4fv(leíró, 1, GL_FALSE, matrixpointer) segítségével beállítjuk azt.

Források

http://en.wikipedia.org/wiki/Transformation_matrix

http://en.wikipedia.org/wiki/Rotation_matrix#General_rotations

http://www.songho.ca/opengl/gl_transform.html

A Blendert mindig is egy fekete báránynak tekintettem a 3D programok között, amolyan szegény ember modellezőjének. A különböző demó produkciók elkészítésénél ki is próbáltam néhány programot, hogy megismerjem erősségüket, gyengeségüket. Végül az ízlésemnek leginkább a 3D Studio felelt meg. Ebben kezdtem el tanulgatni a modellezés alapelemeit.

Az eltelt két-három évben ha nem is lettem profi, egyszerűbb modelleket össze tudtam rakni. Aki nagyon kíváncsi, miket is alkottam, az megnézheti az Aeronautism-ban a léghajót, a 2010-ben az Amigát és az EVA pod-ot. Ahogy egyre ügyesebb lettem 3D Studioban, annál inkább mellőztem a Blendert, pedig telepítve van a Linuxos gépemre.

Ahogy a demóink is egyre fejlődnek (még ha ezt a nézők el sem hiszik :-) ) újabb és újabb igényeink lettek, amit alapvetően kétféle módon oldhatunk meg:

1. A speciális igényeinkhez valamilyen demóeszközt írok
2. Mások demóeszközeit használjuk saját célunkra
3. Egy meglévő eszközt ruházunk fel bővítmények segítségével

Demóeszközt eddig is írtam, de mind nagyon speciális volt, főleg különböző formátum konverziókat hajtottak végre. Egy interaktív eszköz elkészítésén is gondolkodtam, de egyrészt sok idő, másrészt olyan egyszerű problémákra sem találtam kielégítő megoldást, mint amilyen a keresztplatformos futtatás.

Mások egyközeivel is kísérleteztünk. Ezek sajnos kevéssé dokumentáltak, főleg saját használatra lettek tervezve, amitől a kezelésük egyéni logikán alapul.

A bővítmény készítés sem volt egyszerű. Először is a legtöbb 3D program Windows alatt fut (1. rossz pont), C++-ban kell hozzájuk fejleszteni (2. rossz pont). Ennek ellenére elkezdtem tanulmányozni a bővítmények dokumentációit.

Így jutottam el ismét a Blenderhez. Python. Ezt a nyelvet sem szeretem jobban, mint a C++-t. Ráadásul még kevésbé ismerem. Viszont amikor négy sorból megkaptam a kamera pozícióját, mindezt a Blenderen belül, akkor úgy döntöttem, hogy érdemes foglalkozni a programmal. A nyelv mélyebb ismerete nélkül pár nap alatt hozzáfértem egy csontváz elemeihez és megkaptam mely csúcspontok tartoznak a csonthoz.

De nézzünk néhány példát! A Blender elindítása után az ablak típusát változtassuk Script Window-ra. A Scripts -> System -> Interactive Python Console menüponttal megkapjuk az konzolt, ahol egyből be is írhatjuk a parancsokat. Arra ügyeljünk, hogy csak akkor tudunk beírni ebbe az ablakba, ha az egérmutató fölötte van. Gyorsan gépelők ne lepődjenek meg: A shift + szóköz billentyű teljes képernyőssé varázsolja az ablakot.

Objektumok:

Az objektumok listája a következő módon érhető el:

for object in bpy.data.scenes.active.objects:
  print object.type

Aki más 3D programban ennél egyszerűbben meg tudja ezt csinálni, az azonnal tudassa velem! Az objektumok helyzetét és forgásszögeit a következő metódusokkal, tagváltozókkal lehet lekérdezni:

object.getLocation() # Az objektum helyzete
object.getEuler()    # A forgásszögek radiánban
object.LocX          # Csak az X pozíció
object.RotX          # X tengely körüli forgatás szöge (fok)
A legszebb az egészben, hogy bármikor segítséget kérhetünk magától a rendszertől!

dir(object)          # Kilistázza a metódusokat és tagváltozókat
help(object)         # Rövid segítség

Az objektumokat is azonnal módosíthatjuk scripteken keresztül. Például forgassuk meg az első alakzatot, ami a kezünk ügyébe kerül:

for o in bpy.data.scenes.active.objects:
   if o.type == 'Mesh':
      mesh = o
      break;
for rad in range(0,360):
   mesh.RotX = rad
   Blender.Redraw()
Az egyik alakzat őrült forgásba fog kezdeni. Remélem sikerült felkeltenem az érdeklődést ez iránt a program iránt. Habár modellezni még jó ideig nem fogok benne, a jelenetek összeállításában biztosan ki fogom használni a képességeit.

A Velencei-tó mellett töltött nyaralás alkalmából megtekintettük a Madárdal tanösvényt. A túra Dinnyésről indul, de az idegenforgalmi kiadványokkal ellentétben nem egészen onnan kell indulni, ahol a térképek jelzik. A térkép szerint ugyanis azt mutatja, hogy a Gárdonyi Géza utcán kelet felé tartva a Kossuth utca után kell letérni. Ez nem igaz, a Kossuth utcán kell menni, egészen addig, amíg egy kis díszes tábla nem jelzi, hogy hol kell elhagyni a civilizációt.

Maga a tanösvény szépen rendezett, kiépített, ismeretterjesztő táblákkal van ellátva. Elhelyezkedése is igen szerencsés, mert végig egy szegélytársulás mentén halad. A szegélytársulások két eltérő élőhely határán fordulnak elő, és jellemző rájuk az ott élő állatok keveredése. Tehát egyszerre lehet látni a lápi és mezei madarakat.

Az egyetem alatt az ökológia professzorom azt mondta, hogy déli napsütésben épeszű ember nem keres madarat, mert azok elbújnak a hőség elől. (Mondta mindezt egy nyári terepgyakorlaton 12 órakor) Ennek ellenére most is elkövettük ezt a hibát, mert nem volt kedvünk hajnalban felkelni. Még így is meglepően sok madarat sikerült észlelni. (Igaz, némelyiket csak hang alapján tudtuk beazonosítani)

Egy kilátót is építettek a nádas szélére, ahonnan egy jobb távcsővel be lehetett látni a nyílt vízre, ahol a gázló és vízi madarak kolóniáját láthattuk. Az elkészült képekért elnézést kérek, nem támasztottam le eléggé a gépet.

 A gólyáknak nagyon melegük volt.

 Repülő nagy kócsag

Nagy kócsag felszállása

 Ilyen és ehhez hasonló táblák nyújtottak felvilágosítást

A madarak azt hitték senki nem látja őket

Daniel Blankenberg: NGS best practices through Galaxy: Cloudbased variant discovery with visual analytics

Ebben az előadásban a Galaxy rendszert ismerhették meg a hallgatók. A program előnye, hogy ingyenes, felhő alapú megoldást nyújt (természetesen az Amazon használatáért fizetni kell). Az egyetlen szűk keresztmetszet az adatok feljuttatása. Az előadó FTP szervert javasol, mert a kézi feltöltés nagyon sok időt vesz igénybe. A program egyébként ismert eljárásokat tartalmaz, például a variációk megtalálására a GATK-t. Személy szerint úgy gondolom, hogy a Pipeline Pilot felhasználóbarátabb. A húzd és vidd módszerrel összeállított munkafolyamat helyett itt egy webes menü-masszából kell kiválasztani a szükséges lépéseket és az sem segít a helyzeten, hogy rendszeresen átugrik egy olyan ablakra, ahol az eddigi lépések szöveges felsorolása szerepel. Az ablakok elrendezése is elég ijesztő, de az előadó gyakorlott mozdulatai miatt ez nem volt feltűnő. Ha viszont elrejti előlem a GATK összes nyűgjét a különböző formátum konverziókkal együtt, akkor egy próbát megér.

Mivel nem tervezem, hogy több előadásra bemegyek, ezért röviden az általam érdekesebbnek ítélt poszterekről írok egy-két sort.

Jalview 2.7: Nyílt forrású, Java alapú genom nézegető.

Mutalyzer 2.0: Improved sequence variant descriptions from next generation sequencing data and locus-specific mutation databases: www.mutalyzer.nl

SNP4Disease: SNP-betegség adatbázis. http://snp4disease.mpi-bn.mpg.de

UCSC Cancer Genome Browser: Az UCSC-ben immár nem csak "átlagos" genomokat böngészhetünk, hanem rákos genomokat is.

SARUMAN - Using GPU programming for short read mapping: GPU alapú short read mapper Cikk, amire hivatkozik: Exact and complete short read alignment to unihal genome using graphics processing unit (Bioinformatics)

Multi-Image Genome Viewer (MIG): mig.molbiol.ox.ac.uk/mig Bevallom, ez csak a neve miatt tetszett meg. A pószter is egy vadászgépet ábrázolt.

SNPeffect 4.0: molecular and structural phenotyping of human SNPs and disease mutations: Adatbázis, ami SNP-hez rendeli a különböző fehérjeváltozásokat.

SNPsyn: detection and exploration of SNP-SNP interactions: Több SNP egymásra hatását próbálja meg szemléltetni és megkeresni.

GARM - Genome assembly, reconciliation and merging: Szekvencia összeszerelő program, ami hibrid módszert használ.

GenomeView: Egy újabb genom böngésző http://genomview.org

Sequence assembly in the clouds: Búza genomot szereltek össze. Míg sokan azt hiszik, hogy az ember a legnagyobb kihívás a maga 3GB-os genomjával, addig a búzánál 15GB-al kell megbírkózni. Ehhez elosztott rendszer kell.

Chipster genome browser: A Chipsterről meghallgattam az előadást is. Igazából meg kell nézni, mert a poszter arról szól, hogy ők a legjobbak.

Earmark graph approach to de-novo genome assembly: Az oroszok megint kitaláltak valamit. A de-Brujin gráf összeszerelő programok helyett ők az Earmark gráfot javasolják, mert kevesebb memória kell neki és jobb eredményt ad repetitív szakaszokon.

The SMALT software for the efficient and accurate alignment of DNA sequence reads: Újabb mappelő program. http://sanger.ac.uk/software/smalt Olyan gyors, mint a BWA, olyan érzékeny, mint a Stampy, de ahol mégsem olyan érzékeny, ott természetesen elhanyagolható a különbség.

KILAPE - Automated scaffolding and finishing of large, highly repetitive genomes: Ez csak nagyobb darabokat illeszt össze, nem csinál teljes de-novot, de bármilyen de-novo programmal összeeresztve sokkal jobb eredményt kapunk, mintha csak egyedül használnánk a programot.

Inproved in silico regulatory SNP detection facilitates large scale SNP scanning: Megállapítja, hogy az SNP szabályozó régióba esik-e és ez kihat-e a fehérje átírására. http://genomics.csse.unideb.edu.au/is-rSNP

Improving SNV calling sensitivity by combining SNVs reported by different calling tools: Ha SNP-ket akar keresni az ember, akkor legjobb, ha több módszert használ, és a közös variációkat szedi ki. De melyik módszer a legjobb? Azt nem tudják. Próbálják megállapítani, hogy mennyire vegyék figyelembe az egyes programok eredményeit. Azt ők is megerősítik, hogy a GATK újraillesztési lépése megnöveli a megtalálható SNP-k számát, de az új SNP felfedezésében a SAMTools programja jár az élen, még akkor is, ha több fals pozitív eredménye van.

Comparison of short read aligners for ABI Solid platform: Több mappelő programot hasonlítottak össze és az jött ki, hogy a BWA a legjobb, a PerM pedig a legrosszabb.

Két pószterben is benne voltam, nem csak egyben, mint ahogy korábban hittem. Ez több feladatot rótt rám, mert én voltam az egyedüli jelenlévő előadó mindkettőben. A kollégáktól próbáltam segítséget kérni, csak annyira, hogy küldjék hozzám az érdeklődőket. Ezt meg is ígérték, de nem tették. Igen, kiérdemeltem a balek négyzet plecsnit. Ezért egyszer itt álltam, egyszer ott. Elég sok embert érdekelt, aminek örülök. Röviden leírom őket:

Az első pószter arról szól, hogy a legtöbb mappelő program illesztését felhasználva a GATK nem képes olyan polimorfizmusokat megtalálni, ahol a két nukleotid változás közvetlenül egymás mellett van. A második pedig arról szólt, hogy egy kodon alapú mappelő algoritmus jobban teljesít exomok esetén, míg a hagyományos, nukleotid alapú jobban boldogul homopolimer szakaszokon.

Rengeteg könyvkiadó cég is képviseltette magát és a konferencia alatt 20%-al olcsóbban lehetett megvenni sok könyvet. Azt hiszem könyvre bármennyi pénzt el tudok költeni, ezért szerencse, hogy nem volt nálam elég pénz, mert romlásba döntöttem volna a családi kasszát.

Összességében elmondható, hogy a legtöbb kiállító a gyorsaságra helyezte a hangsúlyt. Két kiállító FPGA gyorsítást ajánlott. Megtekinthettünk egy PCI foglalatba illeszthető FPGA gyorsító kártyát. Az előadások is arról szóltak, melyik algoritmus gyorsabb. Még tőlem is megkérdezték, hogy milyen a kodonos illesztő sebessége.

Végezetül egy kis poén. Az egyik kiállító ingyen pólókat osztogatott. Az érdekes az egészben az volt, hogy a cég logója nagyon kicsi volt, viszont egy hatalmas "Blast the unknown" és "Altschul et. al 1337" felirat volt az elején és a hátulján. Mondanom sem kell, vitték, mint a cukrot. Ekkor a cégünktől valaki megkérdezte, hogy ez milyen cikkre hivatkozik. (A válasz: Blast) Körülbelül olyan volt, mintha egy Forma 1 nagydíjon valaki megkérdezi, ki is az a Schumacher?

A második nap először a posztereket néztem át reggel. A poszter szekció is két részre volt osztva, ezért azokról egy külön részben fogok beszámolni. A mai nap nagy dilemmában voltam, mert több előadásra is szívesen mentem (lógtam) volna, amelyek egy időben voltak.

Scott Markel, Ruth Dunn: Analyzing next gen sequencing data with Pipeline Pilot

Ez egy viszonylag hosszabb előadás volt, ahol a Pipeline Pilot nevű keretrendszert mutatták be. A többi bioinformatikai keretrendszertől eltérően ez egy elosztott megközelítést használ, ahol a lokális adatok a feldolozási lépések során egy távoli szerverre kerülnek, majd a további elemzések ott folytatódnak, csökkentve a saját gép terheit. Azért kíváncsi lennék, hogy egy 300GB-os humán short read adat mennyi idő alatt mászik fel a szerverre és hogyan kezelik a feltöltés során fellépő hálózati problémákat. A bemutató során csak pici teszt adatokkal játszottak az előadók, ahol természetesen minden tökéletesen ment.

A másik nagyon szimpatikus megközelítés a munkafolyamatok összeállításának lehetősége. Gyakorlatilag képzeljünk el, hogy a különböző programok be és kimeneteit összekapcsoljuk egy grafikus felületen. Az előadás végén megkérdeztem, hogy segít-e a program a hibás adatok felderítésében, amire azt a választ kaptam, hogy igen. Erről azért a gyakorlatban is szívesen megbizonyosodnék, mert a Bioscope tapasztalatom kétkedésre int.

Az előadásnak volt egy másik érdekes eseménye is. Mellettem egy ember tollal, papírra jegyzetelt!

Susan Gottesman: RNA structure: Bacterial small RNAs in regulatory networks.

Részletes és mélyreható bemutatót láthattunk az E. coli rpoS gén kisRNS-en keresztül történő szabályozásáról. A kisRNS-ek különböző stresszhelyzetben aktíválódnak és bonyolult szabályozási folyamatokon keresztül aktiválják vagy represszálják a géneket. Egy kisRNS több gént is szabályozhat és több kisRNS szabályozhat egy gént.

Peter Rice: EMBOSS: New developments and extended data access

Az EMBOSS egy olyan programcsomag, ami sokszor kihúzott a bioinformatikai slamasztikából. Ennyit megérdemelnek, hogy megnézzem az előadásukat. Az új fejlesztés az adatbázisokhoz való kapcsolódás. Beépített adatbázisok is vannak. Van natív Windows-os verziója is, amit alig tesztelnek, úgyhogy el lehet felejteni a cygwin-t. Az új generációs szekvencia adatok támogatása későbbre tolódott. Szomorú hír, hogy az EMBOSS-nak otthont adó EBI ez év december végétől csak tárhely formájában támogatja a programot. Az előadó még nem tudja, mit fognak tenni.

Eric Tannier: Mapping ancestral genomes with massive gene loss: a matrix sandwich problem

Ősi genomokat próbálnak előállítani a mai leszármazottakból, a gének módosulásait figyelve. A probléma akkor van, amikor a két leszármazott más-más géneket tartalmaz. Nem tudni, hogy melyiket örökölte és melyik keletkezett újonan. Az előadó mátrixokat olvasott fel az előadás nagy részében, amitől nagyon unalmas volt.

Eija Korpelainen: Chipster 2.0: User-friendl NGS data analysis software with interactive genome browser

Egy újabb világmegváltó programcsomag. Elsősorban microarray adatok feldolgozására tervezték, de időközben kapott EMBOSS integrációt, és most a 2.0 verzióban újgenerációs adatokat is képes feldolgozni. Tartalmaz felhő alapú modult is, a Hadoop-BAM-ot, ami egy BAM fájlt darabol, hogy mapreduce-os környezetben fel lehessen dolgozni. Egy genom böngészőt is tartalmaz, ami kevés memória mellett is rendezi a BAM fájl rekordjait a könnyű megjelenítés végett. Az előadás külön érdekesssége volt, hogy a Windows-os laptop nem érte el a Wi-Fi hálózatot, ami miatt egy Machintosnak kellett megmentenie az előadást.

Paul Horton: Next-generation genome alignment with LAST

A Blast a múltté. Az adaptív seed technikának köszönhetően készítettek egy olyan lokális illesztőt, ami gyorsabb és érzékenyebb, minat a BLAST, miközben a repetitív szakaszokon jobban teljesít, mint a nagy előd. Másképp kezeli az indexet, mint a Blast. Egy suffix tömböt használ, ami kevesebb tárhelyet emészt fel, mint egy hash alapú index. Állítólag két gerinces genomot néhány óra alatt illeszt egy átlagos PC-n 2GB memóriával. Egy próbát megér: http://last.cbrc.jp/

Ma is álltam és vártam, hogy az embereknek elmondhassam cégem profilját. Senkivel nem kellett beszélnem. Arra a pár emberre, aki jött, lecsaptak a főnökök, én meg nem tiltakoztam. A munkatársaim pósztere mellett is ácsorogtam, mert ők nem akartak olyan sokat ácsorogni a saját pószterük mellett, úgyhogy megkaphatom a balek plecsnit. Annak ellenére, hogy a nevem nem szerepel rajta és a nullához közelítő mennyiséget dolgoztam vele, elég jól elmondtam annak a három embernek, akik odatévedtek. Ez igen rossz arány egy több ezres nemzetközi konferencián.

Vicces volt, ahogy a háromból kettő kínai kutató volt, akik minden kérdésre adott válaszomat hatalmas "hoo"-val kísértek. Mikor azt mondtam nekik, hogy a short readek referenciához illesztésére saját fejlesztésű programot használtunk, kitört belőlük egy "AHHHHH" mély torokhangon, mintha puszta kézzel vágtunk volna ki egy fát.

Este részt vehettem egy céges munka vacsorán is. A két cég főnökei jól elvoltak a repülőgépes, szállodás történetekkel. Hiába, egy kozmopolita életben ezek az események. Én egyfolytában arra gondoltam, mennyivel hasznosabban tölthetném ezt az időt.

A mai poszt egy bécsi bioinformatikai konferenciáról érkezik. A cég, ahol dolgozom kiállít és előadást tart, én személy szerint poszterrel is jelen vagyok. A bécsi konferencia központban van a rendezvény, ami egy hatalmas épület, felszerelve minden technikával, amivel egy konferenciaközpont fel lehet szerelve. A legutóbbi konferencia óta, ahol voltam, sok minden változott. Régen még a regisztrált tagok tollat és jegyzetfüzetet kaptak. Ma már kevésbé trendi bioinformatikusok laptoppal, a trendik tablettel rohangálnak és jegyzik fel az előadáson elhangzott értékes mondatokat.

Apropó előadások. Sajnos csak kiállítói regisztrációm volt, ami nem tette lehetővé, hogy az előadásokat is megtekintsem, legalábbis elméletileg. Gyakorlatilag a kártyámat megfordítottam, hogy ne lássák rajta a nagy vörös betűkkel kiírt "Exhibitor only" feliratot, szépen mosolyogtam az ajtóknál álló emberekre és máris bent voltam.

A következő előadásokat tekintettem meg:

Andre Altman: vipR: Variant identification in pooled DNA using R

Az előadás lényege az volt, hogy a vizsgálatok során, ahelyett, hogy egyenként klón könyvtárakat készítenének a vizsgálat populációkból, ami idő és erőforrás igényes feladat, a mintákat összekeverik, és a kevert mintából készítenek könyvtárat. Elvesztik az egyéni különbségeket, de cserébe a genetikai variációk jobban csoportosíthatóak. Az előadó azt a példát hozta, hogy egy fehérje diszfunkciójához különböző mutációk vezethetnek, amelyek nem feltétlenül egy helyen alakulnak ki. Az előadás többi része arról szólt, hogy az ő megoldásuk természetesen a legjobb, leggyorsabb.

Samuel Flores: A structural and dynamical model of human telomerase

Bevallom, ebből az előadásból nem értettem semmit. Először azt hittem rossz helyen vagyok, mert az előadó az RNS másodlagos szerkezetéről beszélt, majd a fehérjék szerkezetéről. Az előadás egy hatalmas termet kapott, amit nem sikerült halgatósággal megtölteni, akik végigszenvedték, azok kérdés nélkül távoztak. Lehet, hogy nem voltam egyedül az értetlenségemmel?

Benoit Ballester: Five vertebrate ChIP-seq reveals the evolutionary dynamics of transcription factor binding

Szerintem a legjobb előadás volt ezen a napon, az általam látottakból. Öt gerinces faj kromatin immunpercipitációs vizsgálatával figyeltek konzerválódott transzkripciós faktor kötőhelyeket. Megállapították, hogy milyen mutációk vezettek ahhoz, hogy a transzkripciós faktor egyes fajokban működésképtelen legyen. Figyelték azt is, hogyan változnak bizonyos transzkripciós faktorok más fajokban. Eredményeik még publikálatlanok, de biztosan érdekes cikk fog születni belőle.

Attila Bérces: Cloud computing for computational biology

Magyar előadó is volt, már csak ezért is meg kellett nézni. Arról szólt, hogy nincs mese, a felhő jelenti a megoldást a bioinformatika minden problémájára, mert olcsó, nagyobb teljesítményű. Bármikor leakaszthatunk egy 64GB RAM-al ellátott virtuális gépet, ha szükségünk van rá. Egy hallgató megjegyezte, hogy neki páciensek adataival kell dolgozni, a felhő alapú megoldások milyen biztonságot garantálnak neki? A válasz az volt, hogy még semmilyet.

Attila Bérces: Accurate genome variant detection

A második előadást is meghallgattam. Egy olyan programot mutatottak be, ami mindennél jobban illeszti az újgenerációs szekvenciákat referencia genomhoz. Eddig SOLID platformhoz volt használható, de már készül az Illumina platformhoz szánt változat is. Szokásos táblázatok, hogy ez a jó, minden más semmit sem ér.

George Vacek: Efficient graph based assembly of short-read sequences on a hybrid core architecture

Az előadás a felhő alapú szolgáltatásokkal ellentétben a brutális gépi megoldást preferálja. Egy FPGA foglalatos gépről van szó, ami egyesíti egy PC hatalmas memóriáját és egy FPGA sokmagos gyorsaságát. A cég elsősorban ezen gépek értékesítésével foglalkozik, a szekvenciák összeszerelésére Velvetet használnak, amit kiegészítettek egy saját programmal, hogy a Velvet memória éhségét csökkentsék. Implementálnak más algoritmusokat is eme szörnyeteg alá.

Paul Medvedev: Error correction of high-throughput sequencing datasets with non-uniform coverage

Nagyon sokan nézték ezt az előadást. A teremben az állóhelyek is elfogytak. Egy élelmes kutató kinyitotta a szomszédos termet, majd vigyorogva leült, de mikor az ajtót is elállták előle, biztos arcára fagyott a mosoly. Az előadás lényege, hogy a readeket a fedettség függvényében csoportokba rendezik és nézik, hogy az egy csoportba tartozó readek milyen eltéréseket mutatnak és ezeket a többi read (és nem a referencia alapján) korrigálják. Az számomra továbbra sem tiszta, hogy a heterozigóta SNP-ket hogyan nem javítják ki.

Egyéb látnivalók

A regisztrációs kártya nyakba akasztható volt. Az egyéb információkat (valaki előadást tart, csak egy napra váltott jegyet) kis matricákkal oldották meg, amelyek lelógnak a kártya alatt. Erre egy lapáttal rátett az egyik kiállító is, aki pont ilyen matricákat osztogat azoknak, akik náluk publikálták egy cikküket. El lehet képzelni, hogy milyen hosszú élettörténetet viselhetnek egyesek a nyakukban.

Egy kisebb kiállítás is volt, ahol biológiával kapcsolatos művészi alkotásokat lehetett megtekinteni. Az egyik festményen fehérje térszerkezetek körvonalai voltak kiegészítve arra, amire leginkább hasonlítottak. Volt egy BioBlender nevű programmal készített ioncsatorna és sugárkövetéssel előállított fehérje másodlagos szerkezet.

Közben a cég kiállított standján is beszéltem az emberekkel. A nyomulós, mi vagyunk a legjobbak szöveg helyett inkább azt próbáltam mondani, hogy van akadémiai liszensz, a termékünk kipróbálható. Ezzel az emberek saját maguk eldönthetik, hogy a programunk jó-e vagy nem.

Holnap lesz a második nap, és újabb bejegyzés.

A filmekben a ragasztószalag amolyan univerzális javító alapanyag. Bármilyen javítási feladatot meg tudnak oldani vele. Nekem is van olyan anyagom, amivel bármit megjavítok. Ez pedig a két komponensű epoxi gyanta.

Előnye, hogy bármilyen külön álló darabokat végérvényesen egybe lehet forrasztani vele, ami azután hő, fagy, sav és még ki tudja mennyi hatásnak ellenáll. A fotós állványom egy éjszakai bevetés során megrongálódott, aminek hatására az egyik teleszkópos lábát nem lehetett semmilyen magasságban rögzíteni.

Az ismerőseim mind azt tanácsolták, hogy vegyek újat, de szükségtelennek tartottam, hiszen még volt két jó lába.

Abban biztos voltam, hogy ha egy csavart bele tudnék operálni, akkor azzal megszoríthatnám a lábat. A terv az volt, hogy fúrok egy lyukat, amibe egy anya csavart rögzítek epoxi gyantával. Így sikerült:

 Arra kellett csak vigyáznom, hogy a gyanta bele ne folyjon az anyába és az állvány lábához, mert akkor örökre fix hosszúságú lesz. Ezt kis papírdarabokkal oldottam meg.

Nem tagadom, hogy a mindennapi világ történései alól kivonom magam. Legalábbis megpróbálom. Ezért én csak utólag hallok vulkánkitörésekről, meteorokról, árvízekről, Amerikában tevékenykedő orosz kémekről vagy esetleg járványokról.

A mostani eset sem azért jutott tudomásomra, mert a napi sajtót olvasom, hanem mert egy igen érdekes jelenség tűnt fel vele kapcsolatban.

Mint az ismeretes, Németországban járvány tört ki, a fertőzést egy Escherichia coli nevű baktérium egyik törzse okozta. A kínai BGI saját állítása szerint három nap alatt megszekvenálta a baktériumot és a Twitteren keresztül azonnal szétkürtölték a világban. Annyira siettek, hogy a szekvenciát nem is a nagy genom adatbázisokba töltötték fel először, ahogy türelmes kutatókhoz illik, hanem saját FTP oldalukra.

Feltételezem nem sokat aludtak, mert mindjárt szekvencia analízisnek vetették alá a nyers szekvenciákat. Június 2-án már fel is rakták oldalukra, mit találtak. Az eredmények alapján elkezdtek kiteket gyártani, hogy megkönnyítsék a baktérium detektálását.

Június 7-én már készen volt az a PCR gyors teszt protokolja, amivel 2-3 óra alatt ki lehet mutatni, hogy a veszélyes kórokozóról van-e szó. Számítógéppel leellenőriztek 4547 törzset, ami nem nagy szám, tekintve, hogy az E. coli genomja igen kicsi, kitömörítve 5MB helyet foglal. Ha le is töltötték az összes genomot, akkor is kb. 22 GB helyet foglalt. Viszont kísérletesen 93 törzset is megnéztek. Egy kisebb PCR készülékben 25 cső fér el, a nagyobbakba, ha mikroplate-ba rakják a mintát, akkor 96. Futtatáskor egy csőbe csak reakcióelegyet is tesznek, minta nélkül, hogy megnézzék, történt-e szennyezés. Akkor is két üres hely maradna egy plate-en. Nem hiszem, hogy üresen hagyták volna. Azt tudom elképzelni, hogy azok a minták nem adtak eredményt, vagy valamit elrontott, aki összemérte az oldatokat :-) (Bár külföldi laborokban nem ritka a pipettázó robot) Természetesen az is lehet, hogy ott egyéb kontroll oldatok voltak. Akár hogy is történt, akkor is csak egy PCR-t használtak, mert azt nem tartom valószínűnek, hogy ne legyen 93-nál több E. coli mintájuk.

Visszatérve a történetünkhöz. Június 16-án elkészült a teljes összeillesztés. Itt valószínűleg már nem rohantak, mert egy baktérium genom összeszerelése nem tart 9 napig egy kellően erős számítógéppel. Itt valószínűleg a minőségre mentek rá.

Ugyanakkor létrehoztak a Githubon egy csomópontot, ahol gyorsan meg lehet osztani a további eredményeket.

 Csak, hogy érezzük, milyen gyorsan jöttek ezek az eredmények. Mikor nekem E. colit kellett szekvenálnom (2004), akkor kb. 500 bázispár távolságra "láttunk el". Ezt kb. egy hét alatt kaptuk meg a szekvenáló cégtől. Mivel spóroltunk, ezért a szekvenálási hibákat kézzel javítottuk (mert a PhD-s olcsóbb, mint újból megszekvenálni a hibás részeket). Akkor már megvolt az E. coli egyik törzsének a genomja, tehát ha az alapján tervezem meg a primereket, akkor kb. 11 ezer szekvenálásra lett volna szükség. (Ebbe nem számítottam bele a palazmidokat) Ha nem is lett volna egy hét minden egyes szekvenálás, hanem csak egy óra, akkor is egy évig kellett volna dolgoznunk rajta.

Egyes hírek azt sugallják, hogy ezt csak a kínaiak tudják megtenni, mert ők sokan vannak, jól felszereltek és nagyon akarnak, de nem erről van szó. A felszerelésük tényleg jó és minden bizonnyal nagyon akartak, de a nagy ember mennyiségről nem vagyok meggyőződve. A szekvenáláshoz használt Ion Torrent készüléket egyetlen embernek kell kezelni. A PCR szintén egy emberes készülék. A de novo szekvencia összeépítést leszámítva az összes bioinformatikai munkát el lehet végezni egy közepes PC-n. Ehhez is csak egy ember kell. De ha az Amazonon bérelnek egy sok memóriás gépet, akkor egy laptop is elég a munkához.

Nyilván azért is siettek, mert sok beteg emberről van szó, de észrevehetjük, hogy nem a szokványos tudományos publikálást választották. Ha Nature cikket írtak volna (mint ahogy egészen biztos vagyok benne, hogy fognak), annak a megjelenése több hónap is lehet. Annyi idő elteltével nem lenne a gyorsaságuknak hírértéke. Gyorsan lecsaptak egy aktuális eseményre és nagyon ügyesen meglovagolták a sikert. Hiszen az már egyik hírcsatorna sem említi, hogy miután kihozták a szekvenciákat június 2-án, azóta párszor még frissítették azokat. A gyorsaság miatt még arra sem jutott idejük, hogy a honlapjukon a legalapvetőbb szóelválasztási hibákat kijavítsák.

Tehát egyfelől ott a tény, hogy gyorsan el kell juttatni az információkat azokhoz, akik dolgozni tudnak vele (az első eredmények megmutatták, hogy felesleges bizonyos antibiotikumok alkalmazása, a kórokozóban található rezisztencia gének jelenléte miatt), valamint jelezni kell, a többi kutatólaboratóriumnak, hogy mi már itt tartunk, ti ne ezzel foglalkozzatok. Másfelől egy Github miként tudja garantálni, hogy BGI csomópontjához csatlakozók mindegyike szakember-e?

Én személy szerint örülök, hogy egy okostelefon segítségével a Twitteren keresztül bárhol értesülhetek egy tudományos eredmény születéséről. Azt is szeretem, hogy bár nem vagyok az akadémiai szféra tagja, mégis közel mehetek az eredményekhez, mintha csak egy látogatóknak felállított üvegfalon keresztül nézném a laboratóriumban dolgozókat. De azon is elgondolkodom, hogy hol jobb kutatni? Egy vásártér kellős közepén, ahol a kofa hangosan ecseteli, hogy mit pipettázik a kutató, vagy egy laboratórium magányában? Ezzel a nagy nyíltsággal nem vesztünk-e el valamit?

A Mozilla Labs böngészőben futó demóknak szervez partit. A nevezett alkotásoknak a cég legújabb böngészőjén kell futnia. Öt kategóriát állítottak fel:

• Animált GIF. Ez egyfajta grafikai kategóriának felel meg.
• Egy effektes compo: Ez párhuzamot mutat egy introval.
• CSS3 Compo: Ezt nem tudom minek megfeleltetni. A lényeg, hogy csak CSS3 manipulálást engedélyeznek?
• Audio demo: A compo zenei kategóriája. Lehet generált zenével is indulni, mintha csak executable music compo lenne.
• Full Demo: Ahol csak a képzelet szab határt.

Ha valakinek megtetszett a kiírás és úgy érzi nem tudja hol álljon neki, az látogassa meg ezt a blogot.

Azt hiszem jó hatással vagyok a mukatársaimra. Eddig könnyedén kijelentettek dolgokat, majd mindenféle ellenőrzés nélkül elterjesztették, amit később mások igaznak fogadtak el. Ilyen kijelentés például, hogy az Amazonon a programok futását az I/O műveletek visszafogják. Ilyenkor én mindig megkérdeztem, hogy mire alapozzák a kijelentésüket, van-e bizonyítél, esetleg megmérték-e valamilyen módszerrel.

Szép lassan eljutottunk oda, hogy validálunk, ellenőrzünk, és nem csak valami homályos látomás alapján teszünk kijelentéseket, hanem tények birtokában.

De én továbbra is csak egy kis morzsa vagyok a gépezetben. Még nincs doktorim sem. Mi történik, ha két különböző ember elméletileg hasonló mérése nem egyezik meg? Mi történik, ha egy híres, külföldön tanító professzor egyszerű vizsgálatát megismétlem, és különböző eredményt kapok? Ez a professzor pedig nagyon híres. Egy zseni, egy művész. Olyan gondolatok megálmodója, amire mások képtelenek.

Vele szemben én egy senki vagyok. A proffal már találkoztam, de annak ellenére, hogy többé-kevésbé egy témán dolgozunk, a nevemet sem tudja.

Ilyenkor az a reakció, hogy bizonyára én szúrtam el a vizsgálatot. Ennek megfelelően leellenőriztem a vizsgálat menetét és megismételtem azt. A különbség megmaradt. Hibakeresés, hiba megtalálása. Az eredmények megváltoztak, de a különbség továbbra is megmaradt. Végül eljutottam oda, hogy minden apró hibát kijavítottam, amit csak találtam, de a különbség megmaradt.

Ezek után kénytelen voltam levonni a következtetést, hogy a sztárprofesszor megoldása a hibás. Csakhogy hiába mondom, hogy többszöri ellenőrzés után is ott a különbség. A főnököm, aki rá sem nézett az adatokra, sem a vizsgálat menetére, egészen biztos benne, hogy csakis én szúrhattam el valamilyen lépést. A professzort nem lehet megkérni, hogy egy ilyen bagatel hiba felderítésében segítsen, pláne nem lehet feltételezni, hogy ő elronthat valamit. Helyette egy másik ember, tőlem függetlenül megismétli a vizsgálatokat. Majd utána kiderül, hogy merjük-e zavarni a nagy embert.

Szerkesztés: A megoldás roppant egyszerű volt, nem ugyan azokat a paramétereket használtuk, tehát mindenkinek igaza volt.

Már elég idő eltelt a 2010-es Function óta. Azt hiszem eléggé feldolgoztam a sokkot, hogy kiírjam magamból az ott történteket. Amikor a repülőgépes katasztrófákat felderítik, akkor legtöbbször megállapítják, hogy olyan sorozatos hibákat követtek el, ami külön-külön orvosolható lett volna, de abban a kombinációban olyan halálos elegyet alkotott, hogy a gép nem élhette túl. Körülbelül az én esetem is ilyen volt.

Egy szeptemberi hétvégén volt a Function nevű demoshow. Már jó ideje készültem rá, hogy végre megmutathassam, hogy nem
csak windows alatt lehet jó demót készíteni. Szombaton érkeztem a parti helyére, még időben, hogy
leadhassam Grass kézi rajzát és feltöltsem a demót. A demó rengeteg nagy méretű textúrát tartalmazott,
több részletes poligonnal, ezért nem meglepő, hogy bizony a mérete 39 MB-ra rúgott.

Szerencsére 64mb volt a mérethatár, így ez nem okozott gondot. Ez volt az első demóm, ahol nem a jól
ismert SDL könyvtár képezte a keretrendszert, hanem alacsony szintű függvényhívások: libpng a textúráknak,
vorbis a zene dekódolásának, alsa a hang lejátszásához, X11 az ablakkezeléshez. OpenGL tudásomat is
fejlesztettem, ezért már shaderek is voltak a demó egyes jeleneteiben, ami megakadályozta, hogy
a céges laptopon futtassam.

A parti előtt két nappal gyakorlatilag kész voltam a teljes demóval. Annyit elárulok, hogy Slackware 13.0-n
fejlesztettem, méghozzá 64 bites rendszeren. Ekkor még nem volt semmi információm arról, hogy milyen
Linuxon akarják majd levetíteni a demót, de a tavalyi tapasztalatok alapján abból a feltételezésből
indultam ki, hogy egy 32 bites Ubuntu lesz a compógép.

Telepítetem az Ubuntut, lefordítottam a demót és láss csodát, nem volt hang. Tulajdonképpen nem
lepett meg, hiszen itt PulsAudio van, aminek az Alsa-s emulációja nem teljes. Példának okáért
hiányzik az aszinkron hanglejátszás. Mondanom sem kell, hogy természetesen én azt implementáltam.

Gyorsan felvettem egy új függvényt a cg_audio.c-be, ami láss csodát, tökéletesen működött. Csak nem
Slackware alatt. Itt kellett volna még tovább finomítani a rendszert, hogy mindkét rendszer alatt
tökéletesen menjen, de ezt nem tettem, pedig Richard Marchinko is megmondta: "Soha ne feltételezz!".
Én feltételeztem. Mégpedig azt, hogy Ubuntu alatt fogják lejátszani.

A parti nagy fordulópontja az volt, mikor találkoztam Gargajjal, az egyik szervezővel. Megkérdeztem
tőle, volt-e bármilyen probléma a demóm lejátszásával.
- Ha nem Linuxos, akkor nincs vele gond - válaszolta.
- De Linuxos.
- Itt van a laptopod?
- Itt, de azon nem megy. Kell neki OpenGL 2.0.
Rövid kutakodás után találtunk valakit, akinek szintén volt egy Linuxos laptopja. Rövid próbálgatás után
azt is kiderítettük, hogy ugyancsak Intel GMA-val van felszerelve, nem megy rajta a demóm.

Láttam, hogy a helyzet kezd menthetetlen lenni. Latolgattam, hogyan jutok haza, hogy elhozzam
a saját gépemet. Charlie segített. Képes volt miattam levezetni megközelítőleg 100km-t, hogy
elhozzuk azt a gépet, amin fejlesztettem a demót. Átadtam a szervezőknek és megnyugodtam,
hogy most már semmi baj nem történhet. Ez volt a második hiba.

Az intrók után Gargaj szólt, hogy itt az ideje, hogy beüzemeljem a gépet. Kaptam áramot, hangcsatlakozót,
videó kimenetet. Egy profinak ennyi is biztosan elég lenne, de én azért kértem egy billentyűzetet is.
Hátam mögött a kíváncsi tömeggel nekiáltam az óriás kivetítőn beizzítani a rendszert. A Slackware szép
komótosan indult. Mikor az X11-et indítottam, akkor már láttam, hogy baj van. A gép 640x480 felbontásban volt. Rövid billentyűn
keresztül történő matatás után észrevettem, hogy az NVidia beállítópanel sem ismer nagyobb felbontást,
mint 640x480. Most mi legyen? Kértem egy egeret, amivel kicsit gyorsabban folytattam a matatást.

Mögöttem már kezdett zúgolódni a tömeg. Elindítottam a demót, hátha az majd belövi a felbontást, de nem így történt. A demó bal felső sarka látszott csak.
Végül megnyitottam a forráskódot és átírtam, hogy 640x480-ban fusson le. Ez már nagyon nem tetszett a
nézőknek, hogy ott írom át a kódot. Fordítás sikeres volt, rövid teszt, működik, leállítottam, és szépen hátra
kullogtam.

- Nyomd le az entert! - hangzott fel. Visszafutottam és elindítottam a demót. Ismét hátra kullogtam. A terembe már nem mertem bemenni, csak a folyosóról hallgatóztam és a hangokból próbáltam kitalálni, hogy milyen a demó fogadtatása.

Valami nem stimmel. Miért nem hangosítják fel? Miért nincs hang? Ezt mások is megkérdezték, de nekem akkor nem
esett le. Semmit ötletem nem volt. Közben a demó szépen ment hang nélkül. Emlékeztem, hogy az elején, a teszt alatt még volt. Az első teszt alatt! A
fordítás után már nem! Akkor megértettem. Azt a kódot fordítottam le, ami Ubuntu alatt ment, de Slackware alatt
nem. A demónak a fele akkor már lement. Hallva a bekiabálásokat úgy döntöttem, hagyom így. Úgysem tetszik nekik,
akkor minek fárasszam a nézőket még zenével is? Ennek megfelelően utolsó lett, de akkor már nem foglalkoztam a
dologgal.

Minden esetre megtanultam, hogy atombiztos demót kell írni. Különösen Linux alatt. A másik, ha valami gond van
vele, inkább nem szabad hagyni, hogy lejátszák.

Később visszagondolva több módon is elkerülhettem volna a problémát. Először is, a gépemen volta Ubuntu is. Elindíthattam volna azt is. Normálisan megírhattam volna a kódot (csak egy snd_pcm_recover függvény hiányzott). Nem hagyom, hogy a két kódbázis összekeveredjen. Ehelyett egy olyan elegyet főztem, ami megpecsételte a demó sorsát.

Mivel soha életemben nem foglalkoztam kémiai informatikával
és soha nem installáltam több processzoros gépre semmit, ezért
itt volt az ideje, hogy mind a kettőt kiadják nekem feladatnak.

Az Amazon rendszerén van lehetőség egy 16 processzoros, processzoronként
4 magos gép igénylésére. Erre kellett felvarázsolnom az ADF nevű
programot. Lehetőleg úgy, hogy azt a gépre bejelentkező potenciális
ügyfelek ne tudják ellopni.

Egyszerre csak helyzetet tudok kezelni, ezért az installálással kezdtem.
A program igényel egy MPI implementációt. Ha 64 bites Linuxra szeretné
telepíteni az ember, akkor két lehetőség közül választhat: HP-MPI, vagy
Intel-MPI. Az Intel mellett döntöttem, még akkor is, ha ezzel az Amigás
társadalom mély megvetésére számíthatok.

Az Intel-MPI telepítése nem igényel különösebb leírást, az elavult
telepítési útmutató több-kevésbé lefedi a lépéseket. Pl. Nem kell
liszensz fájl, mint ahogy írják. Az ingyenes futtató környezet
letöltése igaz, regisztrációt igényel, amit csak nagy vonakodva voltam
hajlandó elvégezni.

Az ADF telepítése, még ennél is könnyebb. Egyszerűen kicsomagolja magát
az aktuális könyvtárba, és nesze, használd. Egy liszensz fájlt kell
az ADF könyvtárába másolni, és már készen is áll a kémia titkainak
feltárására. Már ekkor sejtettem, hogy ebből gond lesz. Milyen jogosultságot
tudok adni neki, hogy elrejtsem ezt a felhasználó elől? Ha nincs
olvasási joga a liszensz fájlra, akkor nem indul a program. Ha van,
el tudja lopni. Ezt a problémát későbbre halasztottam és megnéztem, mit
tud a program.

Az ADF Fortran nyelven írt alkalmazás, ami laikusként annyit csinál, hogy
szöveg fájlokat olvas be és szöveg fájlokat ír ki. A bemeneti állományok
atomokat, távolságokat és szögeket tartalmaznak, a kimenet bő beszédű
leírásokat.

A rendszer rész még egy teljes értékű Python értelmező is, ami a körülbelül
180 MB-os programból 120MB-ot foglal el, valamint egy Tcl/Tk is helyet kapott.

A teszt adatok között keresgélve találtam egy érdekeset. Azt elindítottam,
az eredményt összehasonlítottam a példa eredménnyel. Nagyjából megegyezett,
ezért úgy gondoltam, készen is vagyok.

A láthatóság problémáját sodu-val oldottuk meg. Így minden egyes parancsot
sudo-val lesz kénytelen futtatni a felhasználó, de cserébe nem látja még
a könyvtár szerkezetet sem. Hátránya, hogy az eredmény fájlok más
felhasználó alatt (soduer) jelennek meg. Ez még további finomítást igényel.

A gondok itt nem értek véget. Kaptam egy másik teszt adatot, amivel szintén
ki kellett próbálni az ADF-t. Indítás után rögtön azt kaptam a képembe, hogy
nincs host. Hűha! Eddig nem kellett. Gyorsan megnéztem a régi teszt adatokat.
Bizony ott is kellett, csak valami csoda folytán túlélte a program és lefutott,
de most nem. Rövid keresgélés után kiderült, hogy kell egy mpd.hosts fájl.
Rendben, hozzuk létre. De hova? Betettem az /etc-be, a telepítés helyére, de
egyik sem tetszett neki. Végső elkeseredésemben a munkakönyvtárba helyeztem.
Az tetszett neki. Később kiderült, hogy a dokumentáció (nem a getting started,
mert az túl nyilvánvaló lett volna) egy helyen leírta, hogy az mpd.hosts
bizony csak az aktuális munkakönyvtárban helyezhető el. Érdekes! Miért
nem jó az /etc vagy a felhasználó könyvtára?

A következő probléma, hogy nem volt hajlandó egy hoston futni. Tizenhat
processzor van a gépen, de neki nem volt elég, mert csak egy hostot látott.
Beírtam neki tizenhatszor ugyan azt a hostot, de az sem segített. Végül egy trükkhöz folyamodtam.
Az Amazonon minden gépe kap egy nevet. Beírtam azt, és a localhostot. Ez
segített. Viszont nem tudott kapcsolódni saját magához.

Tehát meg kell oldanom, hogy rsh-val a számítógép önmagához kapcsolódjon.
Ez nevetséges. Kell, hogy legyen valami más megoldás. Közben kiderült, hogy
amit én a tesztek idején úgy értelmeztem, hogy lefutott, az valójában nem futott le.
Ugyan az a hibajelenség volt ott is, mint itt.

A megoldás pedig olyan egyszerű volt! Letöltöttem a HP-MPI-s verziót, és
futott minden szépen.

Unatkozik hétvégenként? A számítástechnika túl átlátható? Méretezze át NTFS partícióját!

A céges laptopomon Windows van, de úgy éreztem, hogy Linuxot kell rá telepítenem, anélkül, hogy a Windows törlésre kerülne. Az ok egyszerû: a doktorimat LaTeX alatt készítem, és kell egy olyan megoldás, amivel a akkumulátor barát módon tudom szerkeszteni azt. Erre a legegyszerûbb megoldás a Linux konzol. Konzol alatt sok olyan felaadtot el lehet látni, ami nem igényli a grafikus felületet. Az egyik ilyen a szövegszerkesztés (itt most a szöveges állományok módosítását értem, nem a kiadványszerkesztést).

Ahelyett, hogy valami kereskedelmi programot használtam volna erre, mindezt ingyenes, nyílt forráskódú programokkal akartam megoldani. Azt rögtön sejtettem, hogy a Windows partíció átméretezéséhez elõször defragmentálni kell a fájlrendszert. A rendszer saját programját használtam erre, pedig, mint késõbb megtudtam, ezt a lépést is megcsinálhattam volna Linux alatt. A program finoman szólva is nem hozza a kívánt színvonalt. Többször egymás után el kellett indítani, hogy képes legyen kitölteni a réseket a használat alatt álló blokkok között.

Olvastam, hogy Knoppix alatt megvan minden szükséges program, amivel a Windows partíciókat átméretezzem. A Knoppix egy CD-rõl vagy DVD-rõl futó Linux disztribúció, telepítés nélkül is mûködõképes. Fõleg adminisztrációs célokra használom, tehát nem volt ismeretlen számomra, de csak a 2001-es verzió volt meg. Letöltöttem a legújabb, 6.2-es verziót és nekiláttam a munkának. Gyorsan meg is találtam az NTFS resize programot. A súgó javasolta, hogy ha nem vagyunk biztosak magunkban (én nem voltam), akkor használjuk valamelyik klikkelõs keretrendszert, például a GParted-et. Klikkelõs, egyszerû, bolond biztos. Ez kell nekem! Játszottam az egérrel, húztam-vontam a csúszkákat és a Windows partíció összement. Gondoltam, ha már itt vagyok, elkészítem a Linuxos partíciókat is. Azok elkészítése is gyorsan ment. Végül következett a változtatások kiírása. Ellenõriztem, hogy minden rendben van-e, majd kiadtam a parancsot: írd ki a változtatásokat.

A program jelezte, hogy az NTFS partícióval gond van. A volume mérete nagyobb, mint a drive mérete. Gondoltam, majd átmegyek Windows alá és a chkdsk segítségével orvosolom a dolgot. Itt jött az elsõ fekete leves. Nem tudtam átmenni Win alá. Sem csökkentett módban, sem parancssorban, sehogy. Természetesen semmilyen biztonsági mentést nem csináltam a partíciós tábláról, aminek segítségével könnyedén visszaállíthattam volna a régi állapotot. Eszembe jutott, hogy van Norton Systemworkom, ami annak idején sokszor kihúzott a slamasztikából. Emlékeztem arra is, hogy a CD képes bootolni. Nincs más dologm, mint elõkeresni a CD-t kiírni, majd megoldani ezt a kis malõrt. Nem oldotta meg. Ez egy 2003-as verzió volt, ráadásul egyedül a virus irto indult csak el, amikor bootoltam a CD-vel.

Már láttam magam elõtt, amint a cég rendszergazdája kérdezi, mi történt a laptoppal. Mit mondjak? Leejtettem? Csak Linuxot akartam rá telepíteni és tönkretettem a Win partícióját? Esetleg forduljak a jó öreg kifogáshoz: Nem tudom, egyszer mûködött, de a következõ pillanatban ezt csinálta. Azt tudtam, hogy a fájlok megvannak rajta. Azt is tudtam, hogy ezt vissza lehet hozni. Csak azt nem tudtam, hogyan.

Ekkor léptem meg azt, amit már jóval korábban kellett volna. Rákerestem a Google-n. Kiderült, hogy a GParted rosszul állítja be az NTFS fájlrendszer méretét. Ugyanis annak egy szektorral kevesebbnek kell lennie, mint amennyi rendelkezésre áll. A fórumon egy segítõkész ember a neki elküldött partíciós táblákat javította. Ugy gondoltam, ezt én is meg tudom csinálni. Elõször is a jó öreg dd paranccsal lementettem a partíciós táblát, majd hexeditorral megnyitottam. A második sorban volt a méret letárolva. Kiolvastam a GParted hibanaplójából a méretet, kivontam belõle egyet, a méretet hexadecimálisba alakítottam. Itt egy kicsit tanácstalan voltam, hogy milyen bájtsorrendet kell használni, ezért a fórumban leírt méretek és hexa értékek alapján kisakkoztam. dd-vel visszaírtam a partíciós táblát és különbözõ voodoo szertartások közepette újraindítottam. Múködött! A Linux telepítése ehhez képest már semmi nem volt.

Van egy célom. Szeretnék egy kézzel húzódzkodni. Ehhez nagyon sok húzódzkodást kell csinálni. A házunk előtt van egy szőnyeg poroló, télen viszont nagyon hideg a vascső. A kesztyű nem jó alternatíva, mert nehezíti a fogást. A hideg egyébként is növeli a sérülés veszélyt a gyorsabb kihülés miatt. De az igazi indok, hogy lusta vagyok hidegbe kimenni.

Többször gondolkodtam rajta, milyen megoldást lehet találni a problémára. Végül egy ajtókeretbe feszíthető rúd látszott a legjobb megoldásnak, amit egy ismerősöm lakásában láttam. Azonnal megtetszett a szerkezet egyszerűsége és praktikussága. Szimpatikus volt az is, hogy bármikor eltávolíthatom, anélkül, hogy maradandó károsodást okoznék a lakáson.

Rövid kutakodás után találtam egy hegymászóknak szóló blogot, ahol a hozzászólások között írták, hogy vigyázni kell, mert a rúd talpai benyomódhatnak az ajtókeretbe, célszerű valamilyen talpat használni. Megörültem a hasznos tanácsnak. Igen, erre nem is gondoltam! Szerencsére van néhány használaton kívüli laminált padló, majd abból vágok magamnak megfelelő talpat.

Szépen le is vágtam a padlót a megfelelő méretre, majd ügyesen egyensúlyoztam, hogy miközben csavartam ki a rúd talpait, azok egyenlő távolságra legyenek, valamint a padlóból vágott darabok is az ajtókeret és a talpak között maradjanak mindeközben.

Mikor már a gravitációnak ellenállt a szerkezet, elengedtem a talpakat és tovább tekertem a rudat, hogy jól beleszoruljon a helyére. Már masszívan állt, de én tartva, hogy esetleg mégis kicsúszik, még tekertem rajta. Azután még egy kicsit, csak hogy egészen biztos legyek a dolgomban. Ekkor reccsent egy nagyot az ajtófélfa. Egy hatalmas repedés keletkezett a felső sarkában. Pár hónapja festettem és javítottam le. Szörnyű volt látni, hogyan pusztítottam el a munkámat.

Csak ezután jutott eszembe, hogy van egy másik ajtófélfa is a lakásban, amit nemsokára úgyis ki is fogunk cserélni...

Talán mondanom sem kell, hogy ott semmilyen sérülés nem keletkezett a felszerelés során.

A hazai Amigás közösség legnagyobb összejövetele az AmiCon. Lázi ilyenkor vendégül látja ennek a különleges gépnek a rajongóit, a résztvevők pedig bemutatják, megbeszélik az amigás világ legfrissebb történéseit.

Én friss tagja vagyok a közösségnek, ez volt az első alkalom, hogy részt vettem  az AmiCon-on. Többen is megjegyezték, hogy idén kimagaslóan sokan jöttek el. Ülni csak a korán érkezőknek sikerült.

Az első érdekesség a Hollywood Designer bemutatása volt. Ezt a programot egyetlen Amigás fanatikus fejleszti. Ha a program képességeit le akarnám degradálni, azt mondhatnám, hogy egy Amigás Flash alkalmazásról van szó. Bemutatókat, prezentációkat készíthetünk vele. Interaktív tartalmakat hozhatunk létre segítségével.

Az Amigás közönség alaposan szétforgácsolódott, ahogy egyre újabb és egymással alig-alig kompatibilis rendszer jelent meg. A Hollywood Designer igyekszik minden platformon ugyan azt a felhasználói élményt nyújtani. A Windows és Mac felhasználók sem panaszkodhatnak. A program képes futtatható állományt készíteni a bemutatókról ezekre a platformokra is.

Akik előnybe részesítik a programozást a vizuális szerkesztők helyett, azok a Hollywood beépített szkriptnyelvét használhatják. A bemutatón az is elhangzott, hogy a jövőben C nyelven írt bővítményeket is lehet majd használni.

A másik nagy bejelentés egy új Amigás újság megjelenése volt. A szerzők célja, hogy elsősorban a klasszikus rendszerről jelenítsen meg minél több hasznos információt. A PDF-ben terjesztett verzió ingyenes, a nyomtatott változatért értelemszerűen fizetni kell.

A megjelenésnek természetesen mindenki nagyon örült. Reméljük a szerkesztőknek lesz elég idejük és lelkesedésük is, hogy folytathassák a munkát.

Hallottam egy jópofa történetet is, igaz C64-ről, nem Amigáról. A történet főhőse Ratman, akit egy nap felhívtak, hogy nem megy a program.

- Milyen program? - kérdezte.
- A nyilvántartó program - ekkor kezdett el derengeni neki, miről is lehet szó.

Kiment a helyszínre, ahol talált egy C64-t, egy nyomtatót és egy floppy egységet. Ratman megkérdezte, hogy kivették-e bármikor is a lemezt. Azt mondták nem. Óvatosan kivette a lemezt, amit az idő és a fejmozgás papír vékonyságúra koptatott. Már olvashatatlan volt. Reménykedve megfordította és fellélegzett. Ott volt a forráskód!

Otthon rövid debuggolás után kiderült, hogy mi volt a hiba. A program, ami a kilencvenes évek közepén készült, simán túlélte a PC-s világot fenyegető Y2K-t, de  2008-t már nem. Kijavította a hibát és visszaküldte a programot.

Én még arra voltam kíváncsi, hogy annak idején hogyan tanultak meg kódolni az emberek. Manapság elég megnyitni kedvenc keresőprogramunkat és máris tanulhatjuk a kódolás minden csínját-binját. De ez annak idején lehetetlen volt.

Mint megtudtam, az első lépés, hogy warez forrásból kellett szerezni egy fordító programot. A második lépés, hogy a szükséges dokumentációt (ami legtöbb esetben hibás volt) fénymásolt lapokon be kellett szerezni. Ezt legtöbbször egy lelkes illető lefordította angolról, további hibákat és elírásokat vétve. Végül a programozó palánta beírta és lefagyasztotta vele a gépét.

A tanulás második lépése pedig az volt, hogy ki kellett kísérletezni, mi az, ami működik és mi az, ami nem. Tehát a tudás megszerzése inkább egyfajta felfedezés volt.

GNU/Linux rendszeren sokféle módja van annak, hogy hangot csiholjunk ki a gépből. Itt is megfigyelhető az a tendencia, hogy az eszközök egymásra épülnek és mindegyik célja az, hogy elfedjék szegény programozók elől a problémás részeket.

Ha viszont a lehető leghordozhatóbb megoldásra van szükségünk, akkor célszerű átvágni magunkat az API-k dzsungelén, hogy megleljük a tiszta forrást. Ez nem más, mint az ALSA. Az ALSA segítségével előállíthatunk bármilyen hangot. Szerény véleményem szerint nem olyan bonyolult a használata. Ez azonban nem jelenti azt, hogy nem érhetnek minket meglepetések. Erről majd egy következő bejegyzésben részletesen is írok.

A zenét mi Ogg/Vorbisban tároljuk, ezért a példaprogramban a vorbis könyvtárat is használni fogjuk.

Inicializálás

Első lépés, hogy beállítsuk a kívánt paramétereket. Milyen eszközön, milyen típusú puffert használunk és milyen minőségű hangot kívánunk megszólaltatni.

snd_pcm_open(&playback_handle, "default", SND_PCM_STREAM_PLAYBACK, 0);
   snd_pcm_hw_params_malloc(&hw_params);
   snd_pcm_hw_params_any(playback_handle, hw_params);
   snd_pcm_hw_params_set_access(playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED);
   snd_pcm_hw_params_set_format(playback_handle, hw_params, SND_PCM_FORMAT_S16_LE);
Minden parancs snd_pcm-el kezdődik. Ezt könnyű lesz megjegyezni. Először meg kell nyitni az eszközt. Az eszköz nevét egy sztring határozza meg. Ha több hangkártya is van a gépbe, akkor explicite megadhatjuk, hogy melyik eszközt használjuk. Ha hordozható megoldásra vágyunk, akkor legyen "default".

A második sorban lefoglaljuk a memóriát a paramétereknek, majd beállítjuk azokat. A dokumentáció részletesen leírja, hogy melyik mit jelent. Ezek a beállítások függetlenek a lejátszani kívánt zenétől.

music_file = fopen(argv[i+1], "r");
ov_open(music_file, &music, NULL, 0);
music_info = ov_info(&music, -1);

A zenefájl megnyitása ennyi. A zene jellemzői a music_info struktúrába kerülnek. Ezt fogjuk felhasználni, hogy beállítsuk az ALSA-nak a hangjellemzőket.

snd_pcm_hw_params_set_rate_near(playback_handle, hw_params, &music_info->rate, 0);
   snd_pcm_hw_params_set_channels(playback_handle, hw_params, music_info->channels);
   snd_pcm_hw_params_set_period_size_near(playback_handle, hw_params, &frames, &dir);

   snd_pcm_hw_params(playback_handle, hw_params);
   snd_pcm_hw_params_get_period_size(hw_params, &frames, &dir);
   size = frames * 4;
   buffer = (char *)malloc(size);
   snd_pcm_hw_params_get_period_time(hw_params, &music_info->rate, &dir);
   snd_pcm_hw_params_free(hw_params);
   snd_pcm_prepare(playback_handle);
Ez már kellően elrettentő. A lényege röviden, hogy mi nem adhatjuk meg pontosan a paramétereket, mert az egyes hangkártyák esetleg nem ismerik azt a beállítást. Ezért mi csak annyit mondunk, hogy körül-belül ilyen beállításokat akarunk (snd_pcm_hw_params_set_period_size_near), majd a meghajtóprogram kiválasztja azt, ami a legközelebb esik hozzá, amivel mi már beállíthatjuk a kívánt paramétert (snd_pcm_hw_params_set_period_size). Beállítjuk továbbá a hangpuffer jellemzőit is.

A size = frames * 4 sor egy kis magyarázatot igényel. Az ALSA a pufferben két adatot vár, mivel sztereóban játszunk le. De a másik kettő honnan jön? Azt nem tudom. Bármilyen más értékre átírom, a mintavételezés olyan rossz lesz, hogy élvezhetetlenné válik a zene.

sample_length = ov_read(&music, buffer + pcm_index, bytes_needed, 0, 2, 1, &bitstream);
ret = snd_pcm_writei(playback_handle, buffer, frames);

Gyakorlatilag ennyi a további kód. Az ov_read segítségével kiolvassuk a következő puffernyi adatot, majd az snd_pcm_writei-vel lejátszuk.

A teljes kód:

#include <vorbis/vorbisfile.h>
#include <vorbis/codec.h>
#include <alsa/asoundlib.h>
#include <math.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>

/*
   This program is try to play an ogg-vorbis file. This version
   is working with only in 1 bitstream files.
*/

int main(int argc, char *argv[]){
   int i;
   FILE *music_file;
   OggVorbis_File music;
   vorbis_info *music_info;
   snd_pcm_uframes_t frames = 128;
   snd_pcm_sframes_t ret;
   long sample_length;
   char *buffer;
   int size;
   int bitstream;
   int playing = 1;
   int bytes_needed;
   int pcm_index;
   int dir;

   snd_pcm_hw_params_t *hw_params;
   snd_pcm_t *playback_handle;

   for(i = 1; i < argc; i++){
      if(!strcmp(argv[i], "-f")) music_file = fopen(argv[i+1], "r");
   }

   /* Alsa initialization */
   snd_pcm_open(&playback_handle, "default", SND_PCM_STREAM_PLAYBACK, 0);
   snd_pcm_hw_params_malloc(&hw_params);
   snd_pcm_hw_params_any(playback_handle, hw_params);
   snd_pcm_hw_params_set_access(playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED);
   snd_pcm_hw_params_set_format(playback_handle, hw_params, SND_PCM_FORMAT_S16_LE);

   /* Open the music*/
   ov_open(music_file, &music, NULL, 0);

   /* Get the sample rate information from vorbis file */
   music_info = ov_info(&music, -1);

   /* Set the alsa channels and rate */
   snd_pcm_hw_params_set_rate_near(playback_handle, hw_params, &music_info->rate, 0);
   snd_pcm_hw_params_set_channels(playback_handle, hw_params, music_info->channels);
   snd_pcm_hw_params_set_period_size_near(playback_handle, hw_params, &frames, &dir);

   snd_pcm_hw_params(playback_handle, hw_params);
   snd_pcm_hw_params_get_period_size(hw_params, &frames, &dir);
   size = frames * 2;
   buffer = (char *)malloc(size);
   snd_pcm_hw_params_get_period_time(hw_params, &music_info->rate, &dir);
   snd_pcm_hw_params_free(hw_params);
   snd_pcm_prepare(playback_handle);

  
   while( playing ){
      bytes_needed = size;
      pcm_index = 0;

      while(bytes_needed > 0){
         sample_length = ov_read(&music, buffer + pcm_index, bytes_needed, 0, 2, 1, &bitstream);
         switch(sample_length){
            case 0:
               playing = 0;
               bytes_needed = 0;
               break;
            default:
               pcm_index    += sample_length;
               bytes_needed -= sample_length;
         }
      }
      ret = snd_pcm_writei(playback_handle, buffer, frames);
      if(ret < 0){
         ret = snd_pcm_recover(playback_handle, ret, 0);
         printf("Recover\n");
      }
      if(ret < 0){
         printf("Underrun: %s\n", snd_strerror(ret));
      }
   }

   snd_pcm_close(playback_handle);
   ov_clear(&music);
   return(EXIT_SUCCESS);
}

A demók elkészítése során számos segédeszközt használunk. Az elkészített tartalmakat (zenék, képek, stb) lehetőleg minél kevesebb munkával szeretnénk a demó részévé tenni, ezért a gondosan megválasztott fájlformátumoknak nagy szerepe van. Az intrók esetében ilyen probléma nincs, mert minden tartalmat a program állít elő.

Platform

A demó platformja nagymértékben meghatározza, hogy milyen fájlformátummal tudunk dolgozni. Egy Amigán futó program értelem szerűen nem mp3-ban tárolja a zenét. De PC-n és főleg GNU/Linux rendszerben, ahol a csapat demói készülnek, szintén számítani lehet korlátozásokra. Fedora alatt például alapértelmezetten nincs mp3 codec.

Zene

Mi Ogg/Vorbis formátumban tároljuk a demó hanganyagát. Könnyű hozzá a legelterjedtebb platformokon lejátszó könyvtárat találni. Az SDL_Music például minimális energiabefektetéssel lejátsza. A kezdetek óta használjuk. Valamennyi demónkban Ogg/Vorbis formátumban vannak a zenéink. Egyetlen alkalommal sem okozott problémát a használata, pedig Linux mellett AmigaOS4 és MorphOS alatt is használtam.

Textúrák/Képek

Ez sem nehéz választás. A PNG és JPEG egyaránt elterjedt és népszerű formátum. OpenGL példaprogramok mellett előszeretettel találunk TIFF betöltőket, ezért ha nem akarjuk a képet tömöríteni, akkor ez is egy alkalmazható módszer. Mi PNG-t használunk, mert ebben van alfa csatorna. A libpng-t valamennyi Linux disztribúció tartalmazza. Windows esetén állítólag csak egy DLL kell. Elhiszem. Az összes bitkép szerkesztő program tudja exportálni ebbe a formátumba, de ha mégsem tudna, akkor az ImageMagic ezt is megoldja. (Igen, parancssorban szoktam képeket konvertálni)

3d modellek

Poligon centrikus demók esetén fontos, hogy a különböző térbeli alakzatokat, miután elkészítettük egy modellező program segítségével, szintén minimális energia ráfordítással illeszthessük alkotásunkba. Itt már akadhatnak problémák. Először is, kevés azoknak a fájlformátumoknak a száma, amit a legtöbb modellező program exportálni tud. A másik probléma, hogy az egyes programok ugyanazon formátum különböző dialektusait beszélik. Ezért bármilyen modellt is kapok Grasstól, az első, hogy azonnal tudni akarom, hogy megfelel-e a demó keretrendszere által elvárt formának (ez egyébként valamennyi fájlra igaz).

Így jutottam el a Wavefront OBJ formátumáig. Ez egy szöveges állomány, ezért parancssor segítségével azonnal fel tudom térképezni. Pl:

grep -v "^#" modell.obj | awk '{print $1}' | sort | uniq

Ez a parancs megmondja, hogy mely mezők fordulnak elő a fájlban. A ZBrush például kihagyja a normál vektorokat.

awk '/f/{print NF}' modell.obj | sort | uniq

Ezzel pedig azt ellenőrzöm, hogy minden poligon ugyanannyi csúcspontból áll-e. A Cinema4d ugyanis néha háromnál több csúcsot tartalmazhat.

A másik nagy előnye a szöveges állományoknak, hogy könnyű módosítani őket Perl szkriptekkel. Előfordult ugyanis, hogy az egyik program egy módosítás alkalmával eltolta valamelyik tengely irányába az egész modellt. Mivel én kézzel szoktam pozícionálni a demóban, egy ilyen után meglepődve tapasztaltam, hogy a modell eltűnt. A koordináták gyors ellenőrzése segítségével viszont gyorsan kiderítettem, mi a gond.

Vektorgrafika

Most kellene azt mondanom, hogy SVG. Sajnos nem. Az SVG egy olyan formátum, ami már kétszer is megkeserítette az életemet. Az első demóm alkalmával egy saját vektoros formátumot használtam, de mivel még nem volt grafikus a csapatban, ezért a grafikákat Illustratorban (igen, ez egy Windowsos program) és Karbon14-ben (ez pedig Linuxos) készítettem. Sajnos nem volt elég tapasztalatom egyik program használatában sem, ezért mindkettővel egy részfeladatot végeztem csak el. Abban az időben sokat indítottam újra a gépet.

Ami viszont az újraindításokon túl gondot okozott, az a szabványok támogatásának hiánya. Sajnos az Illustrator, aminek elméletileg kenni-vágnia kellett volna az SVG szabványt, bizony sokszor hibázott. A Karbon14, amit valószínűleg felhasználók visszajelzései nélkül fejlesztettek és fejlesztenek mind a mai napig, viszont remekül boldogult többféle SVG dialektussal is. Ezért, ha véletlenül Karbon14-ből mentett SVG-t akartam betölteni Illustratorba, akkor volt egy kis konvertáló scriptem, ami SVG-t konvertált SVG-be.

Most, így utólag visszaolvasva, nekem is hihetetlennek tűnik, hogy mikre voltam képes. Azt még nem is említettem, hogy az SVG-k csak vonalakat tartalmaztak, egyetlen színnel. Bele sem merek gondolni, hogy mi történt volna, ha bonyolultabb alakzatokat használok.

Sajnos az SVG-től nem sikerült megszabadulnom. Az Etch-a-sketch című demónknál is kísértett szelleme. Itt is saját formátumba készítettük a vektorgrafikát. Okulva a korábbi kudarcból, készítettem egy szerkesztő programot, ami rögtön saját formátumba mentett. Legalábbis ez volt az elmélet. A gyakorlat az volt, hogy sok időt felemésztett a szerkesztő program kifejlesztése, ami nálam működött, Grassnál nem. Közeledett a party, de én ahelyett, hogy a demót programoztam volna, a szerkesztő bugjait javítottam. Grass közben nem tudott dolgozni, az idő meg telt.

Ekkor nagy levegőt vettem és azt mondta, használjunk SVG-t. Két kikötésem volt: Csak vonalat tartalmazhatott és csak egy általa választott program egy bizonyos verziójában készülhetett. Azt gondoltam a konvertáló szkript ennyivel meg fog birkózni.

Mondanom sem kell, hogy egyiket sem sikerült betartani. Szerencsére ezeket idejében észrevettem. A demó pedig elkészült.

Tanulság

A saját formátumoknak megvan az az előnyük, hogy mi tartjuk kézben, viszont több munkát ró a programozóra, akinek el kell készíteni az eszközöket, konvertáló programokat hozzá. A másik lehetőség, hogy standard fájlformátumokat használunk, de itt elképzelhetőek apró módosulások a szabványhoz képest. Ha nem elég robosztus a demó keretrendszere, hogy felismerje a formátum dialektusait, akkor célszerű csak egy program egy adott verzióját használni, és a demót ahhoz igazítani.

Az 1000Genome projekt elérhetővé tett nagy mennyiségű exome szekvenálásból származó adatot. Ezek egy VCF 4.0 típusú fájlban találhatóak meg egy ftp szerveren. Nincs is sok probléma vele, mindössze annyi, hogy tömörítve 61GB. Felhő ide-kimeríthetetlen tárhely oda, ez igen nagy mennyiségű adat, nem sok kedvem volt letölteni, kicsomagolni, majd kinyerni a nekem kellő rekordokat. Szerettem volna valami elegáns megoldást.

Először elkezdtem letölteni, majd egy tetszőleges időpontban megállítottam a letöltést és a zcat segítségével kinyertem az első pár ezer sort. A letöltött állomány darabka 296MB volt, kicsomagolás után csekély 2,3 GB-ra hízott. Tehát 500GB elég lenne a tömörítetlen adatoknak, amelyeknek nagy részére nem is voltam kíváncsi.

Szerencsére a VCFTools rendelkezésre bocsájt egy csomó eszközt, amivel szűrni lehet a VCF fájlokat. Már csak azt kellett megoldani, hogy ez a szűrés letöltés közben valósuljon meg. Mivel GNU/Linux alatt dolgozom, ez nem is olyan nehéz feladat, mint azt elsőre gontoltam.

A letöltést wget-el végzem. Annak a -O - kapcsolóval megadható, hogy a szabványos kimementnek adja át az állományt. A rendszerüzeneteket kikapcsoltam a -q kapcsolóval. Ezután a zcat kicsomagolja az állományt, majd a vcf-subset parancs elvégzi a szűrést. A -c kapcsolóval megadható neki egy fájl, ami a nekünk szükséges sorokat tartalmazza. Összegezve:

wget -O - -q  'ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20100804/ALL.2of4intersection.20100804.genotypes.vcf.gz' | zcat | ./vcf-subset -c oszlopok. >eredmeny.vcf

A BFast egy rendkívül jó kis short read illesztő program. Indexeli a referencia szekvenciát, amitől sebessége elég gyors lesz. Seed technikát alkalmaz, aminek az a lényege, hogy egy 0-ból és 1-ből állo sorozattal megadhatjuk, hogy mely bázisokat hasonlítsa össze és melyeket ne. Volt néhány nem egyértelmű utalás a dokumentációban, amit szeretnék világossá tenni.

Az indexelés 1-től indul

A referencia indexelésénél több seedet is felhasználhatunk, amit indexekkel különböztetünk meg. Ez az index 1-től indul, és nem 0-tól, ahogy egy C programozó várná :-)

A readek FASTQ-ba legyenek

A program FASTQ formátumban olvassa be az adatokat. Ha nem így kapja, segmentation faulttal elszáll. Szerencsére van konvertáló program (solid2fastq), ami még azt a szívességet is megteszi nekünk, hogy szétdarabolja a readeket. Erre akkor lehet szükség, ha nincs elég memóriánk. Amennyiben nem daraboljuk szét a readeket, akkor is megadhatunk intervallumot az -s és -e kapcsolókkal.

Read méret

BFast nem ad optimális eredményt, ha a read mérete kisebb 30 bázispárnál. Ettől függetlenül használható ebben az esetben is, a szerző szerint.

Legyen nukleotid referencia is

Ha color space adatokat dologzunk is fel, a lokális illesztéshez (bfast local) szükség van a nukleotid referenciára is. Ennek segítségével kapjuk meg SAM fájlunkat nukleotidok formájában.

Figyeljünk a kimenetre

A BFast eredményül egy SAM fájlt ad. Ebben megtalálhatóak az illesztett és nem illesztett readek egyaránt. Ez okozhat problémát olyan segédprogramok esetén, mint a Picard SamSort programja, ami ezekkel a readekkel nem tud mit kezdeni, mert nincs pozíciójuk. A nem illesztett rekordokat két módszerrel is kiszűrhetjük: A második oszlop 4. bitje ha be van kapcsolva, akkor a read nem illesztett. A gyakorlatban ez azt jelenti, hogy ha 4 és 20-t találunk, akkor kiszűrhetjük. A másik, vitatható, de jóval gyorsabb módszer, ha a referencia neve helyett (3. oszlop) * karakter van, akkor nem illesztett a read.