HTML

Az élet kódjai

Csináld maga. Senki nem csinálja meg helyetted.

Friss topikok

  • sdani: Sajnos nekem is hasonló érzéseim vannak az R kiszorulásával kapcsolatban. Remélem jobban fogja tar... (2024.04.29. 10:48) R meetup
  • sdani: Nagyon jók ezek a bejegyzések! Feszültséggel teli, fordulatos, mint egy jobb krimi. :D Abba ne hag... (2024.04.29. 10:35) Wgel CTF
  • sdani: @Travis.CG: Egy kis szerencse sosem árt. :D (2024.03.01. 13:19) A bioinformatika helyzete 2024-ben
  • Travis.CG: Szóval az akadémiai szféra mazochistává tett, amit a Pinephone-al élek ki? Hmm, érdekes összefüggé... (2023.10.05. 18:23) Új barátom az Informatikai titkárságról
  • Travis.CG: Túl nagy a hype körülötte, ezért túlzó elvárások vannak vele szembe. Ha a korábbi chatbotokhoz kép... (2023.02.28. 06:28) chatGPT, a bioinformatikus

Részecskerendszerek geometry shaderben

2012.02.02. 22:20 Travis.CG

Az OpenGL 4.0-tól kezdve nem csak csúcspontokként, pixelenként, de primitívenként is futtathatunk programokat. Ez azt jelenti, hogy ha van egy összetett alakzatunk, akkor az azt felépítő háromszögek mindegyikét feldolgozhatjuk shaderrel.

Mit jelent mindez a gyakorlatban? A vertex shader csak egyfajta "ajánlás", hogy miként jelenjen meg az alakzat, a tényleges megvalósítást a geometry shaderre bízhatjuk. Ha ehhez még hozzávesszük azt is, hogy a geometry shaderben új csúcspontokat hozhatunk létre, akkor nem meglepő, ha az ember rögtön azon kezd el gondolkodni, miként használhatja ezt egy demóban.

A koncepció bemutatására egy nagyon egyszerű részecske rendszert fogunk látni, ami halványan egy tüzijátékra emlékeztet. A csúcspontok a CPU-ban kerülnek kiszámításra, majd a geometry shaderben repeszeket adunk hozzá. Mindent pontokként rajzolunk ki.

Először meghatározzuk a csúcspontok helyzetét:

   for(i = 0; i < PARTICLE_NUM * 3; i++){
      pos[i] = drand48() - 0.5;
   }
Véletlenszerűen kiválasztunk néhány koordinátát. Ezután létrehozunk egy vertex array objectet.

   glGenVertexArrays(1, &fire_vao);
   glBindVertexArray(fire_vao);

   glGenBuffers(1, &fire_vbo);
   glBindBuffer(GL_ARRAY_BUFFER, fire_vbo);
   glBufferData(GL_ARRAY_BUFFER, PARTICLE_NUM * 3 * sizeof(GLfloat), pos, GL_STATIC_DRAW);
   glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, NULL);
   glEnableVertexAttribArray(0);
További attribútumokat is megadhatunk újabb bufferek hozzáadásával. Minden attól függ, mennyire összetett részecskéket akarunk. Most csak a pozíció kerül átadásra.

void PlayFirework(){
   double time;
   GLuint uni;

   time = getTimeInterval();
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

   uni = glGetUniformLocation(fire_prg, "time");
   glUniform1f(uni, time);

   glUseProgram(fire_prg);
   glBindVertexArray(fire_vao);
   glDrawArrays(GL_POINTS, 0, PARTICLE_NUM);
}
A megjelenítés abból áll, hogy a csúcspontokat kirajzoljuk a megfelelő shaderrel. Mivel animációt is akarunk, ezért az eltelt időt is elküldjük egy változón keresztül. (time) Végül lássuk a shadereket.

#version 410
layout (location = 0) in vec3 vertex;

void main(void){
   gl_Position = vec4(vertex, 1.0);
}
A vertex shader nem csinál semmi izgalmasat. Megmondjuk neki, hogy a buffer mely attribútumát használja fel, majd tovább is adjuk ezt az információt.

#version 410

layout (points) in;
layout (points, max_vertices = 40) out;

out vec4 color;

uniform float time;

void main(){
  float theta;

  vec4 emitter = gl_in[0].gl_Position;
  float offset = mod(time, 2) / 22.0;

  gl_Position = emitter;
  color = vec4(1.0);
  EmitVertex();
  EndPrimitive();

  for(theta = 0.0; theta < 3.14 * 2.0; theta += 0.2){
     gl_Position.x = emitter.x + offset * sin(theta);
     gl_Position.y = emitter.y + offset * cos(theta);
     color = vec4(1.0 - (offset * 10.0), 0.0, 0.0, 1.0);
     EmitVertex();
     EndPrimitive();
  }
}
A geometry shader végzi a munka oroszlán részét. Megmondjuk, hogy milyen formában fogadjuk a primitíveket. Most pontok vannak beállítva, de természetesen lehetnek háromszöget is, a program felépítésétől függően. Azt is megadjuk, hogy mi a kimeneti primitív típusa. A példában ez is pont. Érdekes, hogy nincs szükség arra, hogy a bemeneti és kimeneti típusok megegyezzenek. Tehát én akár háromszögeket is felépíthetek a bemeneti pontok alapján.

Leírásokban általában nem utalnak rá, de logikus, hogy nem lehet akár mennyi új csúcspontot képezni. Az általam birtokolt kártya megkövetelte, hogy állítsam be ennek maximális számát. Ennek hiányában nem generált hibaüzenetet, de nem is jelenített meg semmit. Nálam maximálisan 256 csúcspontot lehet emittálni. (Eredetileg gömböket akartam rajzolni, de nagyon hamar túlléptem a keretet.) A color kimeneti változót a fragment shader fogja megkapni. A time pedig az idő intervallum, amit szintén a CPU küld át.

Ami a shader szempontjából a legfontosabb, az a gl_in struktúra tömb. A tömb annyi elemet tartalmaz, ahány csúcspontot a primitív. Mivel pontokból kapjuk a csúcspontokat, ezért egyetlen elemet tartalmaz a tömb. A struktúra egyik eleme a pozíció információ (gl_Position)

Az idő alapján kiszámoljuk, mennyire mozdulhatnak el a repeszek a középponttól, erre szolgál az offset. Most jön az első érdekes rész. A gl_Position változónak megadjuk pontosan ugyan azt az értéket, amit megkaptunk. Ez csupán azért kell, hogy lássuk a középpontját a tüzijátéknak. A színe is más a pontnak. Két geometry shader specifikus függvény zárja a szakaszt. Az EmitVertex() jelzi, hogy elkészültünk egy új csúcsponttal, majd az EmitPrimitive(), hogy a primitív is elkészült. Ha háromszögekkel dolgoznánk, akkor háromszor annyi EmitVertex() kellene, mint EmitPrimitive().

Egy ciklusban is csúcspontokat hozunk létre. Egy folyamatosan növekvő kör érintőjén helyezkednek el a csúcsok, és az idővel halványulnak. Két másodpercenként újabb adag részecske keletkezik.

#version 410

layout (location = 0) out vec4 FragColor;
in vec4 color;

void main(void){
   FragColor = color;
}
Végezetül a korábban beállított szín segítségével megjelenítjük a pontokat.

Az új shaderek segítségével egyre több feladatot adhatunk át a GPU-nak. Új alakzatokat hozhatunk létre, és akár egy jó kis demót is írhatunk segítségükkel, mint amilyen a Texas is a keyborderstől. Ez a demó DirectX-es ugyan, de az OpenGL 4 segítségével mi is használhatjuk a technikát.

Szólj hozzá!

Címkék: programozás demoscene opengl

AmigaOS 4.1 update 4

2012.01.19. 21:32 Travis.CG

 Olyan sok mindenről szeretnék írni, de a posztok nagy része megmarad az elhatározás szintjén. Az egyik ilyen téma az AmigaOS 4, amiről már két frissítéssel ezelőtt szerettem volna írni valamit, de elmaradt.

Most pótolom. Már tavaly kijött a negyedik javítócsomag, amit fel is tettem, de még nem írtam le a tapasztalataimat vele kapcsolatban. Kezdjük az elején. Először is, ez nem igazi Amiga. Abban minden Amiga fanatikus egyetért, hogy az Amiga cég becsődölt, az általuk kiadott termékek fejlődése ott megállt, valamikor 1994-ben. Minden, ami utána jön, gyakorlatikag az Amiga életérzés átültetése újabb számítástechnikai eszközökre. Három nagyobb irány van: MorphOS, ami a PPC-s Apple gépeket vette célba, az AmigaOS, ami egyedi fejlesztésű gépekre készül, végül az Aros, ami az x86 architektúrán igyekszik megvetni a lábát.

Ez a három ág mást sem csinál, mint egymást szidja, egymással versenyzik, és mindegyik különböző okokra hivatkozva azt hiszi, hogy az egytlen és egyedüli üdvözítő út az övé. Ez a vita szerintem annyi értelemmel bír, mint a Linux/Windows, Java/C# és a többi unalomig ismert ellentét. Talán azért is látom így, mert én nem vagyok régi Amigás, 2008-óta foglalkozom csak vele. De éppen ezért talán objektívebben látom a kérdést, mint azok, akiknek ez az élete.

De nézzük magát a rendszert. Én egy MicroA1-es gépen futtatom az AmigaOS4.1-t. A gép szerény paraméterekkel bír. Van benne 256MB ram, 800MHz-en ketyegő G3-as PPC processzor és egy ATI Radeon 7000.

Az operációs rendszer egy felhasználós, nincs bejelentkező képernyő. Híján van a memória védelemnek is, amit abból szoktam észrevenni, hogy egyik pillanatról a másikra megáll az egérmutató és ebből az állapotból csak egy újraindítás zökkenti ki. Ha viszont kerüljük a "hirtelen mozdulatokat", akkor nincs sok gond vele. Nézzük, mit lehet kezdeni vele!

Webböngészés

Az internetet az Origin Web Browseren keresztül érhetjük el. Jelen posztot is ebből írom. Nem jelenít meg minden oldalt. Például a YouTube betöltése automatikusan lefagyasztja az egész rendszert, de mivel nincs Flash támogatás, ez nem számít. (MorphOS ilyen téren előrébb jár, ott a HTML5-be ágyazott videókat gond nélkül megnézhetjük). Nagy képeket a kis méretű videómemória miatt lassan tölt be. A JavaScript támogatás megfelelő, a Google Mailben a chat is üzemel. Amit viszont nagyon nem szeretek benne, hogy nem látom, hogy a fájlok letöltése hol tart. Ha egy nagyobb állományt letöltök, akkor annak befejezéséről úgy szerzek tudomást, hogy a routeremen már nem villognak a ledek. A CSS is korrekt, természetesen akadnak oldalak, ahol a formázás rosszul jelenik meg.

Emulátor

A negyedik frissítés hozott egy új emulátort is, amivel állítólag egyszerűbb a klasszikus gépekre írt játékok futtatása. Mivel én inkább demókat szeretek nézni, arra voltam kíváncsi, mennyire fognak ki a demók rajta. Két Amiga 500-ra írt demót próbáltam ki. Egy kis dialógusablak jelenik meg az emulátor elindítása után, ahova fogd és vidd módszerrel bedobhatjuk a futtatni kívánt program ikonját. Ezután megjelenik egy konfiguráció szerkesztő, ahol beállíthatjuk az emulátor paramétereit. Ha végeztünk, elég kettőt kattintani a program ikonjára, amitől elindul egy klasszikus workbench és azon belül a program.

Megpróbáltam a Lightshaftet is futtatni, de nem sikerült. Nem kaptam hibaüzenetet, egyszerűen csak nem indult el. Az emulátorból ezután nem tudtam kilépni, mert a dokumentáció nem említi, hogyan kell. A próbálgatások árán rátaláltam az Alt+q kombinációra, amitől visszajutottam az OS4.1-be. Nem kizárt, hogy a 060-as AGA demókat is lehet futtatni vele, de nekem nem sikerült.

Video lejátszás

Van MPlayer port, annak segítségével lehet videókat lejátszani. Az Amineten fellelhető verziót nem tudjuk használni, de az AmigaSoft oldalán frissebb, működő verzió van. Eddig még nem volt vele problémám. A processzor teljesítménye miatt nagy felbontású tartalmak csak akadozva jelennek meg.

Fejlesztés

Az SDK tartalmaz egy GCC fordítót, kevés dokumentációt, sok példaprogramot, debuggert és egy kisebb Unixos parancsgyűjteményt. Mivel szeretem a Vim szövegszerkesztőt - Linux alatt is azt használom - adta magát, hogy ide is telepítsem. Számomra így nincs különbség az AmigaOS és a Linuxos fejlesztés között. Ami nekem nagyon hiányzik, a dokumentáció. Említettem, hogy nem használtam klasszikus rendszereket, ezért sok programozói megoldás még szokatlan számomra. Van OpenGL támogatás is, ez most már a rendszer részét képezi, nem kell külön letölteni a könyvtárakat. Ugyancsak a rendszer része immár az SDL is. Ezt úgy vettem észre, hogy naívan elindítottam az egyik demónk AmigaOS-es átiratát és ment.

Összegzés

Személy szerint elégedett vagyok az AmigaOS4.1-el. Nem atom stabil (mint ahogy állítják mások), sok hiányossága van, de nem is azért használom, mert minden munkát ezen akarok megcsinálni. Aki erre vágyik, az használjon Windowst vagy Mac-et. Aki viszont a kényelmetlenségek ellenére is olyan rendszert szeretne, aminek egyénisége van, az válassza valamelyik Amiga útját.

 

Szólj hozzá!

Címkék: amiga

Emboss: Szekvencia illesztések

2012.01.16. 15:49 Travis.CG

Korábban megismerkedtünk azokkal az Emboss programokkal, melyek a szekvencia kezelésében segítettek nekünk. Most azt tudjuk meg, mit tehetünk, ha két szekvenciával kell dolgoznunk.

Először is készítsünk teszt adatokat a munkánkhoz a makenucseq paranccsal. Hozzunk létre egyetlen 10 ezer nukleotid hosszúságú szekvenciát. Ha elkészült, adjunk hozzá mutációkat az msbar programmal, és mentsük egy másik állományba.

>makenucseq -amount 1 -length 10000 -outseq test.fasta -auto
>msbar test.fasta -count 40 -point 1 -block 1 -codon 0 -outseq test2.fasta
Van két szekvenciánk, melyek 40 ponton eltérnek. Az első program, amivel megismerkedünk, a needle. A  neve a Needleman-Wunsch algoritmusból származik, tehát ez egy globális illesztőprogram. Hosszú szekvenciáknál, mint amilyen az általunk készített is, nem alkalmazható, mert az illesztéshez felhasznált mátrix nem valószínű, hogy elfér a memóriában. Ezért csak az első 300 bázispáron fogjuk tesztelni.

>needle test.fasta test2.fasta -sbegin1 0 -send1 300 -sbegin2 0 -send2 300 -outfile global.needle -autoA kimenet mutatja a két szekvenciát, amelyet illesztettünk és pipe karakterrel jelzi a tökéletes egyezést.

Ha hosszabb szekvenciákat akarunk illeszteni, akkor a stretcher programhoz fordulhatunk. Ez egy Myers-Miller algoritmust használ, hogy megtalálja nekünk az optimális globális illesztést, miközben a memóriaigénye alacsonyabb, mint a needle-nek.

Lokális illesztéshez is több programot kapunk. A water a klasszikus Smith-Waterman algoritmus megvalósítása, hosszabb szekvenciákhoz ezért nem érdemes használni. Ha mégis nagyratörő terveink vannak. akkor a supermatcherhez fordulhatunk. A paraméterezésük nem tér el lényegesen, ezért csak egy összesítő példa álljon itt a programok használatáról.

>water test.fasta test2.fasta -sbegin1 0 -send1 300 -sbegin2 0 -send2 300 -outfile local.water -auto
>supermatcher test.fasta test2.fasta -outfile local.sm -auto
Ha megnézzük a két eredményt, láthatjuk, hogy a supermatcher bár gyors, rosszabb eredményt ad az első 300 bázispáron, mint a water.

Az Emboss nem tartalmaz programokat olyan problémákra, melyekre már létezik megoldás. Például nincs benne Blast konkures, sem a ClustalW babérjaira törő program. De vannak olyan eszközök, melyek jól kiegészítik ezeket a programokat. Az emma például egy ClustalW-t futtató program. De említhetném például a cons alkalmazást is, ami többszörös illesztésből készít konszenzus szekvenciát. (Ezt egy 23Mb-os SAM állományon próbáltam ki, de fél óra alatt sem futott le.)

Amit viszont feltétlenül érdemes megemlíteni az illesztőprogramok kapcsán, az az illesztés kimeneti formátuma. Valamennyi bemutatott alkalmazás eredményét az -aformat3 kapcsolóval formázhatjuk.

pair/srspair:
atggatatgtggtccggg
||||||||||||||||||
atggatatgtggtccggg

markx0:
tttgcag-acaaccccg
::::::: :::::::::
tttgcagaacaaccccg

markx1:
tttgcag-acaaccccg

tttgcagaacaaccccg

markx2:
gcctttga-----tctc
........TACAT....

Megpróbáltam érzékeltetni, hogy mi vár ránk, ha különböző formátumokat használunk. A blogmotor formázása viszont kifogott rajtam. A markx3 és markx10 formátumok mindkét szekvenciát külön tartalmazzák.

Szólj hozzá!

Címkék: bioinformatika

Szekvencia illesztések megtekintése

2012.01.13. 13:46 Travis.CG

Az ember vizuális típus. Akkor is szereti grafikusan megtekinteni munkája eredményét, ha annak nincs is gyakorlati haszna. Így van ez a bioinformatikában is. Az újgenerációs szekvenálási eredmények grafikus megtekintése időrabló feladat. Az adatok mennyiségét figyelembe véve gyakran szükségtelen. Viszont előfordulhat olyan eset, amikor nem kerülhetjük meg azt, hogy szemünkre és józan eszünkre támaszkodva megnézzük, mi is kaptunk eredményül.

 Jelen posztomban több programot fogok bemutatni, amelyek alkalmasak arra, hogy illesztéseket jelenítsenek meg. Mind kereskedelmi, mind ingyenes programok belekerültek a tesztbe.

EagleView

Első versenyzőnk az EagleView. A programot bináris formában terjesztik, Windows, Linux és MacOSX-re egyaránt letölthető. C++-ban fejlesztették. Akadémiai használatra ingyenes, letölteni regisztráció után lehet. A szerzők szerint még tartalmaz hibákat, amit meg tudok erősíteni. Az Overlapping Size opcióra klikkelve mindig lefagy. Funkció nem sok van benne, tudunk jobbra és balra menni a szekvenciákon. Támogatott fájlformátum egyedül az ACE. Szerintem ezt csak akkor használjuk, ha egy börtön mélyén pisztolyt nyomnak a fejünkhöz.

CLCBio Workbench

A CLC-ről már többször írtam, de még nem részleteztem a megjelenítőjét. A CLCBio Genomics Workbench kereskedelmi termék, 14 napos próbaidővel. Az idő lejárta után sok funkció nem érhető el, de nézegetőnek még használhatjuk. Ingyenes alternatívája a CLC Sequence Viewer, de ez nem képes megnyitni az általunk vizsgált fájlokat.

A program előnye, hogy kereshető benne az adott read neve, referencia szekvencia pozíció. Egyszerűbb szerkesztő funkciók is elérhetőek, mint amilyen az illesztés egy részletének kivágása, elmentése. Többféle formátumot ismer, a referenciára több annotációt is ráhelyezhetünk, ami hasznos, ha funkcionális összefüggéseket keresünk. Egyik nagy hátránya, hogy rendkívül ronda, a másik a readek rendezése, amit igyekszik mindig átrendezni, akárhányszor léptetjük az ablakot. Aki igényli az integrált környezetet, sok pénze van, annak jó választás lehet.

Geneious

A másik kereskedelmi termék a Geneious, amiről már szintén írtam. Ott az eszközök hiányára panaszkodtam, de mi a helyzet vele, mint illesztés megjelenítővel? A felhasználói felület gyönyörű. A basic verziót ingyen használhatjuk, míg az eszközökkel megpakolt termékért fizetni kell. A Linux, Windows, MacOSX verziók mellett Solarisra is elérhető. Java nyelven írták.

Az általam kipróbált példány Fedora 16-on a menüből indítva hibával kilép, de ha belépek a telepítés helyére és onnan indítom, akkor szépen fut.

A kívánt pozíciót gyorsan megkereshetjük az ablak tetején található koordináta segítségével, de akár a nevük alapján is rátalálhatunk a readekre. A menüket egérrel nem tudtam elérni, ami lehet, hogy csak a Fedora 16 egyik sajátossága, de akkor is zavaró volt. Akik nem elégszenek meg a CLC puritán kinézetével, azok nyugodtan válasszák a Geneious-t.

Tablet

Az első program, amivel átléptünk az ingyenes alkalmazások világába, a Tablet. Java nyelven készült, elérhető az összes platformra. Ami nagyon tetszik a Tabletben, hogy több színezési módszerrel emelhetjük ki a nekünk tetsző részletet. Hátránya, hogy a navigálás primitív módon valósult meg. Nem tudunk adott koordinátára ugrani, ami például a humán 1-es kromoszómán igen nehézkessé teszi. ACE, AFG. MAQ, SAM, BAM, SOAP állományokat képes megnyitni, ez elég nagy szabadságot ad. GFF3-ban képes annotációt is betölteni. Tetszik ellenben, hogy kapunk egy áttekintő képet. Automatikusan keresi a frissítéseket, de a felhasználóra bízza, hogy az le akarja-e tölteni vagy telepíteni. Ez is szimpatikus tulajdonsága. Hátránya, hogy semmilyen szerkesztő funckiót nem kapunk. A programot csak az illesztés megtekintésére használhatjuk. Ha ezek nélkül tudunk élni, a Tablet egy remek választás.

IGV

Elérkeztünk a nézegető programok leghíresebbjéhez, az IGV-hez. Egyes cégek, akik pénzért feldolgozzák a nyers szekvenciákat, képesek IGV-t csomagolni az elemzések mellé, hogy a felhasználó láthassa, mit kapott. Azt gondolhatnánk, hogy bizonyára nagyon szép felhasználói felülettel látták el. Nem. Ez a Java nyelven írt program bizony nagyon ronda. Cserébe viszont sok hasznos funkciót kapunk.

Az egyik ezek közül az igvtools, ami segítségével a sam/bam állományokon hajthatunk végre egyszerűbb feladatokat, mint az indexelés vagy sorba rendezés. Ez akkor lehet hasznos, ha a SAM fájlunk nincs koordináták szerint sorba rendezve, és ezt az IGV szóvá teszi. Anélkül, hogy a programból kilépnénk, IGV-kompatibilis állományokat hozhatunk létre. Természetesen az igazi az lenne, ha ezeket a feladatokat automatikusan oldaná meg az IGV, de ne legyünk telhetetlenek. A program hátránya, hogy nincs áttekintő kép, ami miatt először nem is látjuk, hogy hol van és hol nincs lefedettség. Ehhez nagyítani kell. Hosszú szekvenciák esetén ez hátrány, mert sokat kell lépkedni, hogy megtaláljuk azokat a régiókat, ahol nincs lefedettség.

Az IGV-t azoknak ajánlom, akik több illesztést hasonlítanak össze. Ez az eszköz az egyetlen, amelyik egyetlen referenciához több SAM/BAM állományt is be tud tölteni.

Frissítés:

Időközben találtam egy érdekes oldalt, ahol rengeteg vizualizációs eszközt lehet találni:

http://ngslib.i-med.ac.at/taxonomy/term/18

Frissítés 2:

GoldenHelix GenomeBrowser

Nemrég ingyenessé vált a GoldenHelix nézegetője is. A program C++-ban készült, Qt felhasználásával. Nem sűrűn találkozni céggel, akik keresztplatformos C++ programot fejlesztenek (Windows, Linux és MacOSX-re is kiadták, 32 és 64 bites verzióban egyaránt)! Kicsit fanyar szájízt ad, hogy használni csak regisztráció után lehet, ahol összegyűjtik az e-mailt, telefonszámot, stb.

Előnye, hogy rengeteg annotációt képes letölteni a webról. Viszont lokális gépről csak az illesztést képes betölteni, azt is BAM formátumban. Nem mertem kipróbálni, hogy nem sorba rendezett, index nélküli BAM-ot is megnyit-e, valószínűleg nem. A rendkívül szellős dokumentáció szerint IDF állományokat is meg tud nyitni, ami annotációkat tartalmazhat. Szinték képes rá, hogy több BAM-ot is megnyisson egyszerre.

goldenhelix.png

A felület nagyon tetszetős, az indexelt letöltésnek köszönhetően gyorsan megjelenít mindent, de elég kevés funkció van benne. Azoknak ajánlom, akik csak BAM fájlokkal dolgoznak és sokféle annotációt használnak, de lusták letölteni azokat.

Szólj hozzá!

Címkék: bioinformatika

Emboss: szekvencia kezelés

2012.01.08. 20:37 Travis.CG

Korábbi posztomban nagyon kifakadtam a leendő bioinformatikus kollégákra. El is határoztam, hogy írok alapozó posztokat. Ez az első. Jöjjön az EMBOSS gyorstalpaló.

Az Emboss a bioinformatikai svájci bicska. Minden alapvető műveletre megtalálható benne egy vagy több program. Ebben a leírásban elsősorban a szekvencia műveletekre fogok koncentrálni.

Az Emboss parancssoros programokból áll. Két alapvető módon használható. Mindent parancssori kapcsolók segítségével állítunk be, vagy interaktív módon használjuk. Az interaktív módnál a legfontosabb paraméterekre rákérdez a program. Ha kifelejtünk egy kötelező parancssori kapcsolót, a program azonnal rákérdez. Amennyiben megelégszünk az alapértelmezett beállításokkal, -auto kapcsolót használhatjuk.

Az Emboss egyik nagy előnye, ami miatt mindenki szereti, hogy meghatározza, milyen fájlformátumban kapja a bemenetet. Explicit is megadhatjuk neki a formátumot, de az esetek többségében nincs rá szükség, képes kitalálni, mit kapott.

Segítség

Az Emboss rengeteg programot tartalmaz. Ember nincs a világon, aki az összeset ismerné. A wossname segítségével téma szerint kereshetünk programot. Ha nem adunk meg kulcsszót, akkor megkapjuk az összes elérhető program nevét. Ha megtaláltuk a nekünk megfelelő programot, a tfm parancs segítségével részletes leírást kapunk.

Szekvencia feldolgozás

Alapvető igény, hogy általános információkat kapjunk a vizsgálni kívánt szekvenciáról. Például tudni akarjuk a hosszát, mennyi rekordot tartalmaz, stb. Az infoseq programot erre találták ki.

infoseq NC_010473.fnaDisplay basic information about sequences
USA                      Database  Name           Accession      Type Length %GC    Organism            Description
fasta::NC_010473.fna:NC_010473.1 -              NC_010473.1    NC_010473      N    4686137 50.78                      Escherichia coli str. K-12 substr. DH10B chromosome, complete genome

Rengeteg információt ad, egy részük redundáns. A -only kapcsolóval szűkíthetjük a kiírandó oszlopok számát.

infoseq NC_010473.fna -only -usa -lengthDisplay basic information about sequences
USA                      Length
fasta::NC_010473.fna:NC_010473.1 4686137

Máris sokkal szebb.

Említettem, hogy több fájlformátum van. Előfordulhat, hogy ezeket kénytelenek vagyunk konvertálni, kivágni bizonyos részeit. A seqret a mi barátunk. A bemenetet és a kimenetet kell megadnunk neki.
seqret NC_010473.fna raw::outMi az a "raw::"? Itt állítottam be a kimeneti fájl formátumát. Ugyan így megadhatjuk, hogy miként értelmezze a bemeneti fájlt is. Több rekordot tartalmazó fájl esetén megadhatjuk a rekord nevét is, :-al a fájl neve mögött. Pontosan úgy, ahogy az infoseq is kiírja.

A szekvencia kezdő és végpozícióját is megadhatjuk, -sbegin -send kapcsolókkal.

Két különböző forrásból származó szekvencia összehasonlítására a diffseq-t használhatjuk. Ez annyival jobb, mint a Unixos diff parancs, hogy a szekvenciákat hasonlítja össze, nem a fájlokat. Ez akkor lehet hasznos, ha a szekvenciák például különböző szélességű állományokban vannak.

Hasonlóan a fuzznuc-ra is gondolhatunk úgy, mint szekvenciákra kihegyezett grep parancsra. Ideális, ha egy kisebb részszekvenciát akarunk megkeresni egy nagyobban.

fuzznuc test.fa -pattern ACTG -outfile test.fuzzA test.fa állományban megkeressük az ACTG mintázat összes előfordulását, majd az eredményeket a test.fuzz állományba mentjük. Ha a minta reverz komplementerét is meg kívánjuk keresni, akkor a -complement kapcsolót is használnunk kell.

Van két parancs, ami első látársa nem tűnik hasznosnak, pedig segítségükkel új szekvenciákat állíthatunk elő. Ezek a shuffleseq és msbar. Előbbi egy tetszőleges szekvenciát kever össze, míg utóbbi mutációkat hajt végre. Arra is lehetőség van, hogy véletlenszerű szekvenciákat hozzunk létre. Ekkor a makenucseq parancsot kell kiadni.

makenucseq -amount 1 -length 10000 -outseq ki.fa -autoA parancs hatására egy darab 10 ezer nukleotid hosszúságú fájl keletkezik ki.fa néven.

Szólj hozzá!

Címkék: bioinformatika

Cseppet sem objektíven: TUM2011

2012.01.03. 21:09 Travis.CG

Véget ért 2011 decemberének egyik legnagyobb partija a TUM (The Ultimate Meeting). A releasek kezdenek szállingózni, immár bárki megnézheti azokat. Röviden leírom szubjektív véleményemet a kiadott alkotásokról. Igyekeztem mindent megnézni, meghallgatni, de sok esetben nem bírtam idegekkel.

Grafika

Idén sok robotos kép volt. Kedvencem az Invasion begins, Morphinegeneration és a Popwarzen.

Zene

Három féle zenei kategória is volt. Executable music, ahol indítható állományok zenéltek, Loop music, ahol üzenetrögzítő szalagra gyártott zenét a kreatív alkotók, végül trackd music. Nem tetszett egyik sem.

4k intro

Fantáziátlan 4k-k voltak. Egyik sem tetszett.

64k intro

Az Epsilon tényleg lélegzet elállító volt, igaz, csak videón tudtam megnézni. A Transplant nálam bugzott, ennek ellenére szépnek találtam a növényeket. Hozzájuk képest a CoderColors egyszerű volt. Pasyék is képviseltették magukat, a Bozon nevű intróval. A Sparkból ismert részecskerendszert vették alapul, ahol a részecskék most Unreal egyik képévé álltak össze. Gratulálok nekik innen is a negyedik helyezéshez.

Demo

A Mein Zahnfleisch brennt-ben a karatézó robotok tetszettek, de a zene nem az én stílusom. A Tokyo demofest invit egészen jó volt, csak rövid. Jól néztek ki benne a fák. The 3/4 Delusion: A fraktálos rész nagyon tetszett, de a zene itt sem nyerte el a tetszésemet. A táncoló figurák elkészítése a leírás alapján sok időt vehetett igénybe, ennek ellenére elnagyoltnak tűntek. A Verschdl poénjait nem értettem. Az Fr-075 szerintem nagyon jó ötlet. Egy Kis Herceg szerű világot jelenített meg érdekes rajzos shaderekkel, amitől nagyon egyedi hangulatot árasztott. A demó ráadásul futott a gépemen, ami nagy szó. Az Elude meglepő módon most nem Amigás demóval indult. A Suxx a videó alapján nagyon látványos demó, Chaser zenéjét pedig szeretem. A Composed dreams egy musicdisk. Ambientes zenéket játszhatunk le egy nem szokványos kezelőfelületen. Tetszett.

Wild

Csak két entry-t emelnék ki. Az első a Shine, ami bár nem egy világrengető videó, de elég hangulatos, a fiúk igazán megpróbálhatták volna valós időben előállítani. A másik az Introgigademo, ahol szépen összevágtak egy csomó ZX Spectrum demót. Képzeljétek, milyen lehetett a többi induló, ha ezeket emeltem ki.

Szólj hozzá!

Címkék: demoscene

Ezért nem vagyok kódtörő

2012.01.01. 22:10 Travis.CG

Mint annyi más ember, én is ráakadtam a GCHQ honlapjára, ahol egy kódot kellett megfejteni. Egy munkatársam is felfigyelt a képernyőmön látható furcsa jelekre és ő is kedvet kapott egy kis agytornához. (Ez persze nem azt jelenti, hogy mi munkaidőben mással foglalkoznánk! Komolyan, főnök, ez nem igaz!)

Én abból indultam ki, hogy ez egy rejtjeles üzenet lesz, ezért gyorsan írtam egy szkriptet, ami különböző hosszúságú tokenekre bontotta a kódot és megszámolta a gyakoriságot. Társam viszont azt állította rövid szemlélődés után, hogy ez egy programkód és elkezdte visszafejteni assemblybe. Habár a gyakoriság vizsgálat alapján két bájt hosszúnak találtam a jeleket, rájöttem, hogy az üzenet így túl hosszú lenne, ezért biztosan más módszerrel titkosítottak.

Az assemblybe való visszafejtés ígéretesebbnek tűnt, de azzal érveltem, hogy "bármilyne bináris szutykot" vissza lehet assemblyre fordítani. Akkor sem hittem el, hogy ez egy programkód, amikor feltűnt az int 80 megszakítás. (Igaz, ebben az is közrejátszott, hogy a munkatársam rosszul fordította vissza a kódot, amitől minden regiszter ki volt nullázva) Szépen meg is győztem, hogy ez nem lehet programkód. A másik érvem az volt, hogy ha ez kód, hol van az adat tag?

A kérdés viszont nem hagyott nyugodni, ezért pár nappal később rákerestem a neten, hogy mások hol tartanak a megfejtéssel. Szomorúan konstatáltam, hogy bizony ez programkód volt. A honlap segítségével tovább lehetett volna lépni, de rájöttem, hogy ha nem látom meg a jó megoldást (és másokat lebeszélek a jó megoldásról), akkor nem érdemlem meg, hogy folytassam.

Tanultam az esetből. Ha egy ötlet első látásra nem tökéletes, még nem jelenti azt, hogy rossz.

Szólj hozzá!

Címkék: biztonság életmód

Részecskerendszerek fragment shaderben

2011.12.22. 22:28 Travis.CG

Biopunk című demónkban volt egy érdekes effekt, ami egyfajta sejtosztódást próbált meg utánozni. Maga az effekt nem túl bonyolult, egy metaballs implementáció volt 2D-ben. Röviden arról van szó, hogy a képernyőn részecskék mozognak, de minden pixelnél az összes részecskéktől való távolságot összeadjuk, és ez alapján határozzuk meg az adott pixel színét. Itt sokkal részletesebben lehet olvasni róluk.

Organikusnak tűnő alakzatokat lehet vele készíteni, amelyek "nehezen szakadnak" el egymástól. Ideálisak sejtosztódás szimulálására. A megjelenítés módja pedig óhatatlanul azt vonta maga után, hogy fragment shaderben kell elkészíteni.

Az én implementációm csak annyiban különbözött a hétköznapi metaballtól, hogy bizonyos idő elteltével minden részecskéből egy új született. Az új részecske tulajdonságait a GPU-n kívül akartam beállítani. Itt jött az első probléma: hogyan küldjem el a részecskék tulajdonságait (sebesség, életkor, pozíció) a fragment shadernek? Kis számú részecske esetén változóként beadhatom a shadereknek, ez nem probléma, de én 80 darab sejtet akarta.

A megoldás az volt, hogy textúraként adom át a részecske adatokat. CPU-n meghatározom a tulajdonságokat, majd textúrát készítek belőle és hagyom, hogy a megjelenítés nehézségét a shader elvégezze. Csupán egy uniform változót adok át, a részecskék számát (a textúrán kívül, természetesen).

A textúra minden egyes oszlopa egy részecskének felelt meg, a sorok pedig az egyes tulajdonságoknak. Az egyszerúség kedvéért csak egycsatornás textúrát készítettem.

   glGenTextures(1, &celltexture);
   glBindTexture(GL_TEXTURE_2D, celltexture);
   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
   glTexImage2D(GL_TEXTURE_2D, 0, GL_RED, MAXCELLNUM, CELLATTRIBNUM, 0, GL_RED, GL_UNSIGNED_BYTE, 0);
   glBindTexture(GL_TEXTURE_2D, 0);

 Ezután készítettem egy pixel buffer objectet (továbbiakban PBO).

   glGenBuffers(1, &cellbuffer);
   glBindBuffer(GL_PIXEL_UNPACK_BUFFER, cellbuffer);
   glBufferData(GL_PIXEL_UNPACK_BUFFER, sizeof(GLubyte) * MAXCELLNUM * CELLATTRIBNUM, 0, GL_DYNAMIC_DRAW);
A kirajzolásnál frissítettem a PBO-t, majd átmásoltam azt a textúrába (glTexSubImage2D függvény segítségével):

   glBindTexture(GL_TEXTURE_2D, celltexture);
   glBindBuffer(GL_PIXEL_UNPACK_BUFFER, cellbuffer);
   updatePixelData(time);
   /* Copy from PBO to texture */
   glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, MAXCELLNUM, CELLATTRIBNUM, GL_RED, GL_UNSIGNED_BYTE, 0);
   glBindBuffer(GL_PIXEL_UNPACK_BUFFER, 0);
Az updatePixelData tartalmazza a PBO frissítését. A részecskékkel kapcsolatos részt most kihagyom és csak az OpenGL kódra összpontosítok:

   ptr = glMapBuffer(GL_PIXEL_UNPACK_BUFFER, GL_WRITE_ONLY);
   for(i = 0; i < cells.bornedcells; i++){

   /* Particle part skipped */

      ptr[0 * MAXCELLNUM + i] = (65535.0 * cells.cells[i].xpos) / 255.0;
      ptr[1*  MAXCELLNUM + i] = (int)(65535.0 * cells.cells[i].xpos) % 255;
      ptr[2 * MAXCELLNUM + i] = (65535.0 * cells.cells[i].ypos) / 255.0;
      ptr[3 * MAXCELLNUM + i] = (int)(65535.0 * cells.cells[i].ypos) % 255;
   }
   glUnmapBuffer(GL_PIXEL_UNPACK_BUFFER);
Gyakorlatilag a glMapBuffer és glUnmapBuffer a lényeges. Kapunk egy pointert, amin keresztül új értékekkel tölthetjük fel a PBO-t. Mivel nekem megvolt a részecskék összes tulajdonsága a CPU-ban is, ezért GL_WRITE_ONLY-ként határoztam meg a puffert.

A shader a celldata nevű textúrában kapja meg a részecskéket és a texelFetch utasítással olvasom ki az értékeket.

#version 150
#define MIN_THRESHOLD 0.99f
in vec2 texcoord;
out vec4 gl_FragColor;
uniform sampler2D celldata;
uniform int bornedcellnum;

float equation(float radius, float mx, float my, float x, float y){
   return( radius / sqrt( (x-mx)*(x-mx) + (y-my)*(y-my) ) );
}

void main(void){
   int i;
   vec2 cellsize = textureSize(celldata, 0);
   float sum = 0.0;

   for(i = 0; i < bornedcellnum && sum < MIN_THRESHOLD; i++){
      float mxl = texelFetch(celldata, ivec2(i,0), 0).r;
      float mxh = texelFetch(celldata, ivec2(i,1), 0).r;
      float myl = texelFetch(celldata, ivec2(i,2), 0).r;
      float myh = texelFetch(celldata, ivec2(i,3), 0).r;
      float mx = mxl + mxh/256.0;
      float my = myl + myh/256.0;
      float x = texcoord.x;
      float y = texcoord.y;
      sum += equation(0.003, mx, my, x, y);
   }

   if(sum >= MIN_THRESHOLD){
      float c = sum / 3.0;
      c = max(c, 0.5);
      gl_FragColor = vec4(c,c,c,1.0);
   }
   else{
      gl_FragColor = vec4(0.0, 1.0 - distance(texcoord, vec2(0.5)), 0.0, 1.0);
   }
}
A sejtek pozícióit nem elég 8 biten tárolni, ezért a pozíciókat a textúrában két sorban tárolom, azért van ennyi bűvészkedés a sejtek helyzetének meghatározása körül. Gyakorlatilag ez egy tervezési hiba, ha a textúrák nem 1 byte-on tárolnák az adatokat, a kód egyszerűbb lehetne. Aki fel akarja használni a kódot, annak célszerű kijavítani ezt.

A teljes forrás letölthető innen. Az src könyvtárban található celldivide.c fájl tartalmazza a sejtosztódós részt.

Szólj hozzá!

Címkék: programozás demoscene opengl

Szakmák, amikhez mindenki ért: bioinformatika

2011.12.22. 00:56 Travis.CG

Ön tudja nyomkodni a Facebookot? Használt már Windowst? Gratulálunk, Ön mától bioinformatikus! Hogyan? Ön úgy érzi, keveset ért semmit a biológiához? Semmi gond, ez nem akadály. A nukleotidokra gondoljon úgy, mint holmi karakterekre a Wordben, ahol csak négy karaktert kell lenyomni. Látja, könnyebb, mint a gépírás! Úgy látom, még mindig nem hiszi el, hogy Ön bioinformatikus. Mondja, mi még a gondja. A statisztika? A 

statisztika felesleges, gondoljon csak a bikinis hasonlatra. A 

programok úgyis kiírnak valamit. Olyan programot meg úgysem írnak, amelyik ostobaságot írna ki.


Ez után a bevezető után kifejteném, miért látom úgy, hogy a bioinformatikához mindenki ért. A munkahelyemen meghírdettünk egy bioinformatikai állást, amire csak úgy özönlöttek a jelentkezők. Ennyi bioinformatikust még konferencián sem láttam. A jelentkezők legtöbbje Unixot még nem látott. Ez azért probléma, mert a programok legtöbbje Mac-en vagy Linuxon fut. Miért? Mert ezeken van egy olyan parancssor, ami nagyban segíti a munkát. Legtöbbször ugyanis szöveges állományokat kell feldolgozni. Ha van három fájl, azt még egy klikkelős programmal el lehet intézni, de 20 fölött még a legtürelmesebb ember is feladja. Ha viszont van egy jó parancssor, akkor a munka gördülékeny.

Ez elvezet minket oda, hogy kell némi programozói ismeret. Nem muszáj Terminátorokat gépi kódban hekkelni, de a Perl szkriptek ismerete szükséges. Miért Perl? Mert szövegfeldolgozásra kihegyezett programnyelv. Van egy BioPerl modulgyűjtemény, amivel az ismertebb fájlformátumokat feldolgozhatóak. Az EnsEMBL API szintén Perl-ben készült, A nyelv ismerete elengedhetetlen. Ennek ellenére volt olyan jelentkező, aki C#-ban írt egy programot, ami promóter mutációkat szimulált. A gond csak az volt, hogy a program egy tetszőleges szövegen véletlenszerűen megváltoztatott néhány nukleotidot. Ha beírtam volna a Háború és Békét, azt is mutálja. A programnak semmi értelme nem volt, de legalább bebizonyította, hogy a jelölt ért egy olyan programozási nyelvhez, ami irreleváns bioinformatikailag. Az már csak hab a tortán, hogy felhívtuk a figyelmét rá, hogy a program értelmetlen, semmilyen biológiai folyamathoz nincs köze, de csak annyit mondott, még további fejlesztésre szorul. (Azóta sem láttam a Nature címlapján)

Az adatok feldolgozása egy dolog, de nyersanyagot is tudni kell szerezni. Egyik próbafeladatunk alkalmával egy gént kértünk FASTA formátumban. Ha a jelölt nem a Google és Wikipédia oldalakon keresztül jutott a célhoz, már örültünk. Pedig az elsődleges szekvencia adatbázisok minden bioinformatikai kurzusban szerepelnek. Három van belőlük, de mivel ugyan az van mindegyikben, elég egyet megjegyezni.

Azután ott vannak a fura figurák. Ők már a felszínen átrágták magukat, de mégis hihetetlen dolgokat produkálnak. Például egy programozó, aki saját bevallása szerint eddigi munkája során a másodfokú egyenlet megoldóképleténél bonyolultabb matematikai formulát nem használt, elhatározta, hogy szekvencia illesztőt ír. Gondoltam segítek neki irodalommal, hogy mégse kelljen feltalálnia a spanyolviaszt. Mikor meglátta a Smith-Waterman algoritmust, kijelentette, hogy ez csak misztifikálja a problémát. Végül írt egy grep szintű programot. Ez annyira megtetszett neki, hogy tőlem kérdezgette, hogyan tudna bioinformatikusként elhelyezkednie.

A másik érdekes eset az volt, amikor egy másik bioinformatikus wannabe írni kezdett egy illesztőprogramot. Végül belefulladt a feladatba, ezért segítséget kért tőlem. Először elmagyaráztam neki, hogy az ő problémájára nem lesz jó a LCS algoritmus, neki globális illesztő kell. Azt felelte, de ő csak ezt találta letölthető kódban. Utána megpróbáltam megygyőzni, hogy ha már van kész program, nem szükséges fejleszteni. Megmutattam neki a programot, azt is, hogyan kell használni. Ezután közölte, hogy ő ezt Windows alól fogja használni 1500 fájlra. De mivel a PowerShell-t sem ismeri, ezért majd ír egy Java programot, ami meghívja neki az illesztőt. Igen, akinél kalapács van...

A bioinformatika határtudomány, ezért én úgy érzem, soha nem tudhatok eleget, hogy megfeleljek a kihívásoknak. Napi szinten találkozom olyan kérdésekkel, amelyekre nem tudok válaszolni. Legutóbb azt kérdezték tőle, minek a rövidítése a LOH. Nekem is utána kellett néznem.

Mások pedig felületes tudással tökéletesen elvannak. Mi lenne, ha én is azt mondanám: OpenGL-es demókat írok, akkor én játékmotor fejlesztő vagyok. Megszereltem a villanybojlert, akkor megpályázok egy víz-gáz-fűtés szerelői állást. Nevetségesen érezném magam.

Szólj hozzá!

Címkék: filozofálás bioinformatika

Experience 2011

2011.12.11. 22:13 Travis.CG

Idén is megrendezték az Experience demóvetítést. Megismételték a Vakondok 2 bemutatóját, amit kihagytam, majd az idei év legjobb demóiból egy szubjektív gyűjteményt láthattunk nagy kivetítőn.

A teljesség igénye nélkül a következő produkciókat tekinthettük meg:

Struct by Outracks

Spheres on a plane by Dead Roman

numb res by Carillion, Cyberiade, Fairlight

We have accidently borrow your votedisk by Razor1911

A magyar produkcióknak volt egy kisebb díjátadó, ahol a legjobb produkciókra lehetett szavazni 8bites, zene, grafika, mozgókép, soundtrack, 4k és 64k kategóriákban. Csapatunk egyik kategóriában sem nyert gumikacsát, amit fődíjként osztogattak. Nagyon jó hangulatú vetítés volt. Egy kisfiút nagyon felzaklatott az Elektrosokk című alkotás, amiből megállapítottam, hogy egyes demók talán mégsem a gyerekeknek valók.

Ezen a napon volt az AmiCon találkozó is, amire most nem mentem el, de az Amigások eljöttek és bemutattak két produkciót, amit a Revision 2011-en mutattak be. Az egyik az Elude-tól a Shake off the dust volt, a másik a Human Traffic.

Kilenckor leléptem, hogy a ritkábban járó tömegközlekedést elérjem. Rosszul számítottam ki az időt, ezért futnom kellett. Az eső elkezdett esni, a cipőm talpa vizes lett. A hangjelzés pillanatában ugrottam fel a szerelvényre. A vizes talpam kifutott alólam, fenékre ültem, de a lendület tovább vitt és átcsúsztam a kocsi másik végébe. Mindenki rajtam nevetett.

Szólj hozzá!

Címkék: demoscene

Genetikai variációk webinar

2011.11.30. 21:42 Travis.CG

Egy érdekes webinart lattám a mai nap. A genetikai variációk detektálásáról és hatásairól szólt, kihegyezve, hogy milyen betegségeket képesek okozni. Három előadó beszélt, az első (Andrew J. Sharp) bemutatta a genetikai variációk detektálásának elméleti hátterét, míg a másik két előadó (Hakon Hakonarson és Ray E. Hershberger) a gyakorlati alkalmazásokat mutatták be saját tudományterületükről.

Az elmélet

Két fő módszer létezik genetikai variációk kimutatására. Az első a komparatív genom hibridizáció (Array CGH), mint a nevéből is látszik, egy hibridizációs eljárás, míg a második a szekvenáláson alapul. A hibridizációs módszer csak a chip-re felvitt DNS-hez képest egy relatív variációt képes megadni. A chip mérete a detektálható variációk mennyiségét is befolyásolja. Az előadás 4 millió variációt említ, a hibridizálandó szekvencia mérete 25-100bp között mozoghat. A CNV detektálásnál 0-5 ismétlődést képes kimutatni. A cégek speciális igényekhez saját chipeket is rendelkezésre bocsátanak, bizonyára jó pénzért.

A nagy felbontóképességű chipek mikrodeléciókat is képesek kimutatni. Ennek demonstrálására egy TGG repeatet mutattak, amely betegséget okoz, ha hiányzik belőle egy darab.

A szekvenáláson alapuló módszerek két nagy csoportra oszthatók. Az egyik paired-end readeket használ. Ha a referencia genomra illesztés során a read párok távolsága eltér az elvárttól, az delécióra vagy inszercióra utalhat. Ha a readek orientációja változik, akkor inverzió vagy transzlokáció történhetett. Itt megjegyezném, hogy egyes illesztőprogramok eldobhatják a readeket, ha azok túl nagy távolságra vannak egymástól. Egy nagyobb transzlokáció inkább olyan helynek fog látszani, ahova nem illeszkedik egyetlen read sem.

A technológia limitációját a DNS könyvtár mérete dönti el. Ez jelen pillanatban 300-6500 bázispár. Ennél nagyobb deléciókat értelem szerűen nem lehet megtalálni.

Ha nem párosított readeket használunk, akkor az úgynevezett split-read technikával szimulálhatjuk a paired readeket. Itt a read hossza válik limitáló tényezővé. A Mosaik és SOAP2 illesztőprogramok képesek így illeszteni.

A readek mélysége is fontos információt hordozhat az ismétlődő szakaszokról. Ha a referencia egy szakaszán kétszer annyi read fordul elő, mint máshol, akkor az azt is jelentheti, hogy az a szakasz két példányban fordul elő a referenciához képest. Végezetül megemlítették még a de-novo összeszerelést is, mint módszert.

A gyakorlat

A másik két előadó bemutatta, hogy mindez hogyan néz ki a klinikai gyakorlatban. Hakonarson azt mondta, hogy náluk a gyerekklinikán nem csak a gyerekeket, hanem a szülőket is megszekvenálják, hogy megállapíthassák, hogy öröklött vagy szerzett genetikai elváltozás okozza az adott rendellenességet. Találtak az ADHD-val (hiperaktivitás) kapcsolatba hozható genetikai változást, ami egy komplett anyagcsere útvonata blokkol. Terveztek gyógyszert, ami rendbehozza ezt az útvonalat, de a specificitása elég alacsony, ezért az előadó inkább a személyre szabott medicinában látja a jövőt.

A másik példa még grandiózusabb volt. Egy egész családfát megszekvenáltak, hogy megtalálják egy igen ritka genetikai variáció szívizom rendellenességre kifejtett hatását. Teljes exome szekvenálást, és array hibridizációt csináltak. Természetesen megtalálták, amit kerestek.

Kérdések

Volt pár érdekes kérdés a végén. Az egyik az volt, hogy a CNV-k mérete és a betegségek között van-e összefüggés. Azt válaszolták, hogy igazából a technológia fejlődésének köszönhető, hogy egyre kisebb betegség okozó CNV-ket találnak. A másik kérdés az volt, hogy a CNV-k eloszlása véletlenszerű-e? A CNV-k eloszlása nem véletlenszerű, vannak olyan helyek a genomban, ahol a több található, ezek valószínűleg összefüggésben állnak a rekombinációval.

Szólj hozzá!

Címkék: bioinformatika

Sci-fi 1991-ben

2011.11.26. 13:07 Travis.CG

A növényi betegségekről nem tudok túl sokat. Úgy is mondhatnám, semmit, ezért beszereztem egy könyvet "Beteg növények biokémiája és élettana" címmel. A könyv 1991-ben jelent meg, ami azt jelenti, hogy a '80-as évek ismereteit foglalta össze. Logikusan tagolva mutatja be az egészséges növény jellemzőit, majd bemutatja, hogy mit változtat meg a kórokozó jelenléte.

Mint a cím is mutatja, főleg mikroszkópos és kémiai vizsgálatokon keresztül értelmezi a tüneteket, ami mai szemmel nem korszerű, mégis megmagyaráz sok olyan jelenséget, ami feltétlenül szükséges, hogy megértsük, mi is zajlik le egy növényben a fertőzés során.

Ami miatt írni akarok erről a könyvről, az az utolsó fejezet, ahol molekuláris biológiai eredményeket tárgyalnak. Az érdekes benne az, hogy főleg a molekuláris biológiai módszerek nehézségeit tárgyalja. Mikor én tanultam ezekről a módszerekről, akkor már jó részük megoldódott. Azóta pedig még további lehetőségekkel bővült a kutatók eszköztára. Kicsit úgy éreztem magam, mintha egy jövőbeli ember önmagáról olvasna a múltban kiadott sci-fi könyvben.

Például a Nukleinsavak szintjén művelt biotechnológia című fejezetben a következőket írja: "Jelenleg a rezisztenciagéneket egyáltalán nem tudják a kutatók a génproduktumok alapján azonosítani...Ha a rezisztenciagénnek vélt gént a patogén indukálja a növényben, akkor a vizsgálandó növényi szövet teljes mRNS vagy teljes fehérje populációját kellene összehasonlítani a kórokozó nélküli állapotban és fertőzés után." Erre természetesen már megvannak a módszerek. Korábban a különböző expressziós chipeket használták, ma már inkább az RNA-Seq-et.

A bekezdés így folytatódik: " A patogének azonban igen sok stresszgén, illetve betegséggel kapcsolatos gén stb. expresszálódását indíthatják be, amelyek vagy a stresszel, vagy a patogenezissel kapcsolatosak, de nem a betegség elleni rezisztenciával." Szerencsére erre is van megoldás, hiszen bioinformatikai módszerekkel össze lehet hasonlítani stresszindukált növények expressziós mintázatát a patogén indukálta adatokkal.

Szinte minden magára valamit is adó bioinformatikai előadás tartalmaz egy grafikont, ahol feltüntetik a beküldött/feldolgozott szekvenciák számát/mennyiségét. Mégis, csak most értettem meg, hogy ez mit is jelent. Mit jelenthet mindez az információ egy húsz évvel ezelőtti kutatónak, aki a laborjában ülve azon kesereg, hogy nem tud egyetlen rezisztencia gént sem izolálni, mert egy gén azonosítása is több PhD-snak elegendő disszertáció témát ad. Most pedig aki nem állapítja meg több tucat genetikailag módosított növény teljes génexpresszióját, az lusta disznó.

Egy másik érdekes észrevétel, hogy a könyv írója 1991-ben el tudta képzelni, hogy mire lenne szükség a jövőben. Nekem, 20 év távlatából nincs ilyen elképzelésem a jövőről. Természetesen tudok közhelyeket mondani: olcsóbb lesz a genomok szekvenálása, kevesebb hibával, kisebb mennyiségekből is tudnak majd szekvenálni. De ténylegesen mindez mit fog jelenteni? Mik azok a kérdések, melyekre ma még lehetetlen válaszolni, és 20 évet kell várni?

Kicsit úgy érzem, nem én vagyok az egyetlen, aki nem lát előre. A sci-fi is egyfajta válságba került. Asimov idején még a technológia, a jövő technológiája a könyv szerves részét képezte. Ott is voltak gyilkosságok, szerelmek, akár egy tudománytalan-fantáziátlan könyvben, de a technológia jelenléte más ízt adott a témának. Ha megnézzük, William Gibson sem ír már emberekről, akiknek a fejében számítógépes interface van, hanem marketingesekről, akikkel akár már holnap találkozhatunk. Dan Simmons jövőjében pedig az internetre az erdő fái is rá vannak kötve. Nincs is igazi technológia, csak jelenségek, amelyek magyarázat nélkül függenek a levegőben.

Nem azt akarom mondani, hogy ezek a könyvek rosszak, csak azt, hogy akiknek tudniuk kellene milyen lesz a világ (vagy legalábbis irányt kellene mutatniuk), nem tudják. Nem tudják, mert már most sci-fiben élünk. A sci-fi szereplők pedig nem fantáziálnak a jövőről.

Szólj hozzá!

Címkék: filozofálás bioinformatika

Hasznos linkek

2011.11.20. 12:25 Travis.CG

Az interneten történő kalandozásaim során sok érdekes linket találok. Ezeket ebben a posztban fogom gyűjtögetni.

Egy remek prezentáció az újgenerációs szekvenálási módszerekről. StarTrek fanatikusoknak kötelező darab.

Bioinformatikai alapozó. Itt nem a biológiát, hanem az algoritmikus megközelítést mutatják be. Néhány helyen hiányos. Ha bővítik, biztosan remek lesz az alapok elsajátítására.

Nem tudod, mi a de Brujin gráf? Semmi gond. Ha nem vagy otthon a gráfelméletben, itt akkor is képet kapsz a de-novo szekvencia összeszerelésről.

Néhány szeminárium szekvenciák feldolgozásáról. Klinikai elemzésekről is szó van.

Ha inkább blog formájában akarsz értesülni a legújabb eredményekről, íme egy blog, ahol a blogokról írnak.

Szólj hozzá!

Címkék: bioinformatika

Dokumentumfilm a demosceneről

2011.11.18. 14:44 Travis.CG

Tegnap volt a Vakondok 2 című film bemutatója, ami a demoscene-ről szólt. A film logikusan van felépítve. Elindul egy általános bemutatástól kezdve, majd az adott kategória szakértőin keresztül a néző megismerheti a részfolyamatokat is.

Jó volt, hogy kitértek a régi nyolc bites gépekre is. Mikor a filmen felsorolták ezeket a géptípusokat, mellettem egy lány meglepődve megkérdezte: - A C64 csak nyolc bites?

A filmet feldobta még a rengeteg demórészlet, ami az interjúk közötti átmenetben mutattak. Nem mehetek el amellett a részlet mellett, hogy a másodperc tört részéig látszott a 2010 c. demónk. :-) Egy másik demónk zenéje pedig hallatszott.

A filmvetítés helyén képeket is ragasztottak ki a folyosóra. Az összeállítást Grass csinálta. Itt is látható volt egy részlet az egyik demónkból, a Wayangból.

Összességében a film tetszett. Korrekt, alapos munka. A tény pedig, hogy a munkáink - ha csak rövid időre is - látszottak a filmen, azt mutatja, van helyünk a demosceneben.

Frissítés: Időközben elérhető a végleges film letölthető és online formában: innen.

Szólj hozzá!

Címkék: demoscene

Mentsük, ami menthető

2011.11.17. 13:52 Travis.CG

Az egyik szkriptemet elindítottam, majd egy másik munkamenetben véletlenül kitöröltem. Nem volt bonyolult program, de hosszú fájlnevek és elérési utak voltak beledrótozva, amit nem szívesen írtam volna újra.

Mivel még futott, egy munkatársam javasolta, hogy próbáljuk megmenteni. Ext3 fájlrendszert használtam. Az első szóba jöhető program az ext3undel. Az Amazonos Linux csomagjai között nem szerepelt. Ugyan így nem szerepelt az icat sem. Két lehetőség volt, vagy forrásból installálom, vagy másik lehetőséget keresek.

Az lsof parancs megadta az inode számot is, ezért olyan eszközt kerestünk, ami ez alapján fér hozzá a fájlhoz. A find -inum nem segített. Végül megtaláltuk a megoldást.

A /proc könyvtárban megkerestük a process azonosítóját (ezt is kiírja az lsof), beléptünk, majd az fd könyvtárba mentünk. Itt kiválasztottuk azt a fájlt, aminek a száma megegyezett az lsof FD mezőjében leírtakkal. Ez a mi fájlunk. Ezt utána nyugodtan másolhatjuk.

A módszer csak olyan állományok esetén működik, amelyekhez van olvasási jogosultságunk.

Szólj hozzá!

Címkék: rendszergazda

Mese a projektvezetőről, aki elvesztette humorérzékét

2011.11.16. 10:33 Travis.CG

Egyszer volt, hol nem volt, volt egyszer egy projektvezető, aki a Kerek Erdő közepén a törpék életét irányította. Egyik csoportmegbeszélés alkalmával a törpék elé tett egy javaslatot, hogy a munka hatékonyabb végzése érdekében készítsenek egy "protokol templétet" ami kitöltve fokozatosan nyomon következő a törpék munkamenete. Leírhatták volna, hogy milyen csákánnyal bányásznak, mennyire pakolják tele a csillét, hányszor fordulnak meg a csillével a nap folyamán. A nap végén azt is felírhatták volna, hogy mennyi aranyat bányásztak.

A törpék először csak kuncogva hallgatták ezt a töménytelen mennyiségű hülyeséget, de mikor meglátták, hogy a megbeszélés végére a projektvezető már el is készítette a dokumentumot KicsiBanya Word programjával, akkor hangosan hahotázni kezdtek.

- Nagyon szép dokumentumot készítettél - mondta a Bölcs Bagoly, aki szintén részt vett a csoportmegbeszélésen. - De egy ilyen dokumentum csak akkor lesz hasznos a törpéknek, ha már meglelték a lelőhelyet és feltérképezték azt. Most még nem tudják, milyen csillét fognak használni. Előbb ki kell próbálniuk valamennyit. Ha majd megindul a tömegtermelés, akkor nagyon hasznos lesz ez a dokumentum.

A projektvezető elszomorodott, hiszen háromféle betűtípust és színeket is használt, de az észérvek előtt meghajolt. Elmentette a dokumentumot. A megbeszélés hátralévő részében egy szót sem szólt.

Mikor végeztek, néhány törpe megsajnálta és megpróbálta megvigasztalni.

- Nem rajtad vagy az értelmetlen dokumentum mániád miatt nevettünk. De a helyzet olyan vicces volt.

- Én nem tudok nevetni - sóhajtott a projektvezető.

- Miért? - csodálkoztak a törpék.

- A sok projektvezetés hatására úgy érzem elvesztettem a humorérzékemet.

- Ne mond már! Bizonyára nagyon jó humorérzéked van.

-Nem, nincs. Tudjátok én adattárházakkal is foglalkozom egy másik erdőben. Az ottani kollégáim megkértek, hogy meséljek nekik egy viccet.

- Melyik viccet mesélted?

- Egyiket sem. Mutattam nekik egy adatbázis sémát.

Szólj hozzá!

Címkék: irodalom

Megszereztem

2011.11.15. 23:31 Travis.CG

Egy hosszú idő óta húzódó folyamat végére került pont a múlt héten. Végre sikeresen megvédtem doktori címemet. Hosszú vargabetűket írtam le, mire elértem idáig, de megérte. Röviden összefoglalom a főbb állomásokat.

A diákok legtöbbje az egyetemen olyan doktori iskolába megy, ahol már szakdolgozóként is megfordult. Én növényélettannal foglalkoztam és különböző programokat írtam ökológusoknak. Ezért teljesen logikátlan volt, hogy mégis a genetika tanszék doktori programjába kapcsolódtam be. Az ok, hogy ezt tettem nem volt más, mint egy előadás, ahol bioinformatikáról beszéltek. Ekkor éreztem, hogy nekem ezt kell csinálnom. Nem volt genetikai laboratóriumi munkában semmi gyakorlatom. Talán ez is volt az oka, hogy nem haladtam olyan ütemben a vizsgálatokkal, ahogy egy igazi PhD hallgatónak haladnia kellett volna. Cserében viszont műveltem magam. A számítástechnika szakos hallgatók óráira is bejártam, hogy képezzem magam és minél jobb bioinformatikus legyek.

A három év ösztöndíj eltelt, publikációm nem volt, és lehetőségem sem, hogy folytassam a tanszéken a munkát. Gondoltam egy merészet és jelentkeztem egy bioinformatikai kutatócsoportba. Szerencsére felvettek, ezért a PhD-t gyakorlatilag újrakezdtem egy teljesen más témával.

Szerencsére itt jobban haladtam, mint a laboratóriumban. Született egy társszerzős cikkem és úgy tűnt talán lesz egy első szerzős is. Ekkor átszervezték a kutatócsoportot. Először az alacsony rangú munkatársak szerződését nem hosszabbították meg, később már a magas rangúak sem voltak biztonságban.

A munkának nem értem a végére, első szerzős cikkem nem volt. Egy nagy semmi voltam. Néhány ügyetlen próbálkozásom volt, hogy bioinformatikai jellegű területen maradjak, végül sokkal egyszerűbbnek bizonyult elmenni programozónak, annak ellenére is, hogy nem volt szakirányú végzettségem. Esténként és hétvégenként visszajártam a kutatóintézetbe, hogy befejezzem a munkákat, amelyek a publikációhoz szükségesek.

Ez az időszak elég megterhelő volt. A programozói munka után nekilátni egy teljesen más területnek, mindezt fáradtan, sok energiát kívánt. Gyakran öt percig csak néztem a képernyőt és próbáltam kitalálni, hogy miért van szükség arra a lépésre, amit a jegyzőkönyvemben felírtam egy évvel azelőtt. Keservesen lassan haladtam. Néhány hónap után abba is hagytam. Ameddig eljutottam, addig eljutottam.

Közben megjelent egy újabb publikációm is. Egy újabb követelménynek tettem eleget. Gondoltam itt az ideje, hogy elkezdjem írni a doktori disszertációt. A legnagyobb kihívást az okozta, hogy úgy mutassam be a munkámat, mintha az egy kerek egész lenne annak ellenére, hogy ilyen szerencsétlen körülmények között készült. A témavezetőm is máson dolgozott eközben, neki is csak plusz terhet jelentettem.

Programozó karrierem sem tartott olyan sokáig. Két év után a cég leépítette a teljes fejlesztői gárdáját és egy fejlesztőcégnek adták a munkát. Megint ott álltam, ahol a part szakad. Szerencsére ismerőseim felhívták a figyelmemet egy frissen induló bioinformatikai cégre. Jelentkeztem és felvettek. Kicsit olyan volt, mint egy visszatérés.

Végül született egy igen gyenge disszertáció, ami elsőre át sem ment a házi védésen. Ugyanis azt gondoltam, hogy a házi védés csak egy informális, baráti beszélgetés. Nem, nem az. Mikor elmondták, hogy pontozzák az előadásomat, akkor tudtam, hogy végem. Szerencsére megúsztam annyival, hogy meg kellett ismételni az előadást. Ez már jobban sikerült, de a dolgozat is erős átírásra szorult. A tömegközlekedésen és otthon is ezt írtam. Azok, akik vállalták, hogy átnézik a dolgozatot megismerhették diktatórikus oldalamat. Az idő fogyott és noszogatni voltam kénytelen az embereket, hogy időben átnézzék a szöveget.

A dolgozat elkészült. Az opponensek átnézték és úgy találták, ez már megüti egy doktori disszertáció színvonalát. Készülhettem a védésre.

Az időpont egyeztetés a bizottság tagjaival nem volt vészes. Mindenki azzal riogatott, hogy milyen nehéz, de sikerült ebben a hónapban olyan időpontot találni, ami mindenkinek megfelelt. Az előadás elkészítése nem volt bonyolult, mert a jól sikerült házi védést vettem alapul. Igyekeztem kiegészíteni, hogy ne csak azok értsék meg, akik a szűk tudományterület bennfentesei. Ezért egyes helyeken kényszerű egyszerűsítéseket vezettem be.

A védéshez kapcsolódó reprezentatív események megszervezése volt egyedül gond. Rendeltem szendvicseket, vettem kávét, üdítőt, műanyag tányérokat és evőeszközöket. Mindezt bevittem az egyetemre. Egyeztettem az előadás és a fogadás helyét, idejét. Este még egyszer átnéztem az előadást, majd aludni tértem.

Másnap jöttek a problémát. Először is a terem kulcsa máshol volt, mint ahogy mondták. Ezt még elég könnyen lehetett orvosolni. Az étel időben megérkezett, de a kávéfőző elromlott, másikat kellett szerezni. Nekiláttam utoljára elpróbálni az előadást. Ekkor vettem észre, hogy egy nyers opponensi válasz van a gépemen, nem a legfrissebb. Elrohantam az egyetem számítógéptermébe, hogy a levelezésemből kimentsem a legfrissebb verziót. Még szerencse, hogy a hallgatóként használt internetes azonosítóm működött. A projektoron nem látszott az egyik ábrám, mert kicsi volt a kontraszt. Erről el is feledkeztem! Igazából csak egy diát érintett, ezért úgy döntöttem, hagyom, ahogy van. Miután kipakoltunk minden ételt, közölték velünk, hogy a fogadás mégsem ott lesz. Már csak negyed óra volt az előadás kezdéséig, ezért aki élt és mozgott, kaját pakolt, köztük én is. Végül a segítőket kénytelen voltam magukra hagyni, mert előadást kellett tartanom.

Megtartottam az előadást, válaszoltam a feltett kérdésekre. Legnagyobb hibámnak azt tartották, hogy sok biológiai fogalmat rosszul használtam. Ez kellemetlen volt. Ezt leszámítva senkinek nem volt más problémája. A vendégek száma kevesebb volt, mint amire számítottunk, ezért töménytelen mennyiségű szendvics maradt. Két napig azt ette a család és még így is tudtam adni hajléktalanoknak.

Végiggondolva, ez volt eddigi életem legnagyobb kihívása. Az érettségi és az államvizsga is bizonyos szempontból nehéz volt, de szükségszerű következménye volt az adott oktatási intézményben eltöltött időnek. A tanuláson kívül nem kellett semmilyen energiát befektetni. Kis túlzással azt is mondhatnám, hogy determinálva volt, hogy megszerezzem a végzettséget. Azért túlzás, mert volt lemorzsolódás. Itt viszont a hétköznapokat kellett legyőzni.

Köszönöm mindenkinek, aki segített a harcban.

Szólj hozzá!

Címkék: életmód

Régi jó dolgok

2011.11.06. 22:52 Travis.CG

Az idősebb emberek gyakran lenézik a fiatalokat, mert más ismeretekkel rendelkeznek. Az ő szempontjukból ez csak a tudás hiányával magyarázható. Vannak esetek, amikor kiderül, nincs miért lenézni a fiatalokat.

Vonaton utaztunk Nagykanizsára egy barátommal. Mellettünk egy idős úr valamelyik országos terjesztésű napilapot olvasta. Amikor végzett az újsággal, beszélgetni támadt kedve, ami nem szokatlan ilyen helyzetben.

Nem voltam túl közlékeny vele, ezért inkább a barátomnak intézte szavait. Megkérdezte, ismerjük-e azt a fiatalembert, akiről az újságban olvasott. Mivel egyikünk sem olvasta a szóban forgó újságot, ezért nem tudtuk, hogy kire is gondol. Nekem mégis a feltételezés volt furcsa.

- Miből gondolja, hogy ismerjük? - kérdeztem.

- Mert nagykanizsai.

Meglepett a válasz. Azért, mert egy olyan vonaton ülünk, ami Nagykanizsára megy, azt következtette ki utitársunk, hogy ismerjük.

- Nem ismerünk mindenkit a városban - jegyeztem meg, hogy rávilágítsak, mennyire abszurdnak tartom a gondolatmenetét.

- De magukkal egy korú lehet - védekezett az úr.

Mintha minden korosztály egy városban ismerné a másikat. Gyakorlatilag ő csodálkozott azon, hogy miért feltételezem, hogy nem ismerem. Ki is nyitotta az újságot. Egy egy oldalas cikk foglalkozott a fiatalemberrel. Volt is egy kép róla és a családjáról. Természetesen én nem ismertem.

- Az osztálytársam volt! - mondta barátom, aki viszont ismerte.

- Látja? - felelte győzelemtől ittasan az úr.

Barátom a cikk segítségével sok mindent megtudott osztálytársáról, amikor a hideg idő ellenére egy katicabogár szállt a vonat ablakára. Mivel kívül volt, nem látszottak a pettyei, de a jellegzetes alakja nem hagyott kétséget a rendszertani besorolása felől.

Az úr meglátta.

- Egy kullancs! Még szerencse, hogy kint van.

Barátommal megpróbáltuk megmagyarázni, hogy egy katicabogárról van szó.

- Kicsi a feje és nagy a potroha, ez egy kullancs - hajtogatta az úr.

Felhívtam a figyelmét, hogy a kullancsnak nyolc lába van, ennek meg csak hat. Ráadásul egy kullacs csak akkor lehet ilyen nagy, ha már teleszívta vérrel magát, de akkor nem tud felmászni a vonat ablakára.

- Teleszívta magát a tehénen, ami ott legelt a mezőn - hangzott az ellenvélemény. - Maga biológus?

Történetesen olyasmi vagyok, de ha meg tudok különböztetni egy kullancsot egy katicabogártól, akkor csak is biológus lehetek?

Szólj hozzá!

Címkék: filozofálás

Mélységi puffer

2011.10.21. 10:48 Travis.CG

Screen-space ambient occlusion, deferred rendering, shadow mapping. Mi a közös ezekben a fogalmakban? Mindegyik alapja a mélységi pufferben (depth buffer, z-buffer) tárolt információ.

Ha nem akarjuk, hogy a pouet.net-en olyan kritikát kapjunk, mint: "Ez '94-es színvonal", "2000 előtt láttam ilyen demókat", (márpedig én nem akarok :-) többet). Akkor mindenképp meg kell ismerkedni ezekkel a technikákkal. A most következő leírás OpenGL 4.1 alatt fog működni.

Áttekintés

A módszer lényege, hogy először a geometriát (3D objektumokat) rajzoljuk ki egy shaderrel (nevezzük depth shadernek), az eredményt lementjük egy vagy több textúrába. A második fázisban egy, az egész képernyőt betöltő négyzetre kirajzoljuk a textúrát.

A bevezetőben említett technikák csak abban térnek el, hogy miként használjuk pufferünket. Ha egy fényforrás felől állapítjuk meg a távolságot, akkor árnyékokat hozunk létre, ha az egymás közelében elhelyezkedő mélységeket hasonlítjuk össze, akkor SSAO-t alkalmazunk.

Inicializálás

Hozzunk létre egy framebuffert, és csatoljunk hozzá két textúrát. Más források arról írnak, hogy kell egy renderbuffer is, ami szintén tartalmazza a mélységi adatokat, de ez nem igaz. Az viszont igaz, hogy engedélyezni kell a mélységi vizsgálatot.

glEnable(GL_DEPTH_TEST);
glGenFramebuffers(1, &fb);
glBindFramebuffer(GL_FRAMEBUFFER, fb);
glGenTextures(2, textures);

/* Depth information */
glBindTexture(GL_TEXTURE_2D, textures[0]);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT, width, height, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
/* Add more texture parameters if You would like */
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_2D, textures[0]);

/* Color information */
glBindTexture(GL_TEXTURE_2D, textures[1]);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
/* Add more texture parameters if You would like */
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture[1], 0);

if(glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE){
  printf("Error\n");
}

glBindFramebuffer(0);
Már az elején létre kell hozni a "négyzetet" ami megkapja a textúrákat. A koordináták szokás szerint egy vertex arrayben lesznek.

void createSquare(){
   GLfloat v[] = {-1.0, -1.0, 1.0, -1.0, 1.0, 1.0, -1.0, 1.0};

   glGenVertexArrays(1, &square);
   glBindVertexArray(square);
   glGenBuffers(1, &squarevbo);
   glBindBuffer(GL_ARRAY_BUFFER, squarevbo);
   glBufferData(GL_ARRAY_BUFFER, 8 * sizeof(GLfloat), v, GL_STATIC_DRAW);

   glBindVertexArray(0);
}
Szükségünk lesz még két shaderre. Az egyik a textúrákat fogja feltölteni. Mivel nem fog tartalmazni semmi különleges műveletet, ezért csak base_shaderkét hivatkozom rá. A másik a textúrákat fogja kirajzolni a képernyő méretű négyzetre. Ez a shader fog a mélységi pufferrel dolgozni, ezért ennek a depth_shader nevet adtam.

#version 410

/* base_shader vertex part */

in vec3 vertex;
in vec3 normal;

uniform mat4 pmatrix;
uniform mat4 mmatrix;

out float factor;
out float depth;

void main(void){
   vec4 pos = pmatrix * mmatrix * vec4(vertex, 1.0);
   gl_Position = pos;
   factor = max(0.0, dot(normal, vec3(0.0, 2.0, -15.0)));
   depth = pos.z / 15.0;
}
A base_shader rajzolja ki a modelleket, ezért itt alkalmazni kell a mátrix műveleteket, hogy a modelleket eltoljuk, forgassuk. A mélységi adatokat a vertex Z koordinátájából vesszük, miután alkalmaztuk rá az összes mátrix műveletet. A mélységi puffer 0.0-1.0 közötti értékeket vehet fel. Most az egyszerűség kedvéért vegyünk egy olyan jelenetet, ami 0 - 15 közötti koordináták között mozog. A csúcspont Z koordinátáját ezért 15-el elosztjuk. Megjegyzem, ez egy nagyon egyszerű, lineáris mélységi számítás. Realisztikusabb eredményt kapunk, ha a messzebb elhelyezkedő tárgyaknál kisebb felbontást használunk, mint a közelebb elhelyezkedőeknél.

#version 410

/* base_shader fragment part */

in float factor;
in float depth;
out vec4 gl_FragColor;

void main(void){
   gl_FragColor = vec4(1.0) * factor;
   gl_FragDepth = depth;
}
A gl_FragDepth a mélységi pufferünk, míg a gl_FragColor a színeket tartalmazza. A factor változó egy kis változatosságot csempész a színek egyhangúságába.

#version 410

/* depth_shader vertex part */

in vec2 vertex;
out vec2 texcoord;

void main(void){
   gl_Position = vec4(vertex, 0.0, 1.0);
   texcoord = (vertex + 1.0) / 2.0;
}
A négyzetünket nem forgatjuk sehova, csak kirajzoljuk. A textúra koordinátákat a shader számolja ki a csúcspontokat felhasználva.

#version 410

/* depth_shader fragment part */

out vec4 gl_FragColor;
in vec2 texcoord;

uniform sampler2D renderedtex;

void main(void){
   gl_FragColor = vec4(texture(renderedtex, texcoord).r);
}
Most csak egy textúrát kezel a shader. Később, ha majd több pufferünk is lesz, majd kiegészítjük ezt a kódot.

 Rajzolás

A rajzolás két menetben történik. Először a modelleket rajzoljuk ki, letároljuk a textúrákba, majd a második menetben a textúrákat a négyzetre rajzoljuk.

   glBindFramebuffer(GL_FRAMEBUFFER, fb);
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

   glUseProgram(base_shader);
   uni = glGetUniformLocation(base_shader, "pmatrix");
   glUniformMatrix4fv(uni, 1, GL_FALSE, pmatrix);

   uni = glGetUniformLocation(base_shader, "mmatrix");
   glUniformMatrix4fv(uni, 1, GL_FALSE, locM);

   /* Draw the mesh */
   drawMesh3D(tree);
A kódból hiányoznak a mátrix műveletek, csak a kirajzolás váza van itt. A mátrixokról írtam egy korábbi cikkben.

   glUseProgram(depth_shader);
   glBindFramebuffer(GL_FRAMEBUFFER, 0);
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
   glActiveTexture(GL_TEXTURE0);
   /* Color attachment use as texture for a quad */
   glBindTexture(GL_TEXTURE_2D, textures[0]);
   uni = glGetUniformLocation(depth_shader, "renderedtex");
   glUniform1i(uni, 0);

   /* Draw a quad */
   glBindVertexArray(square);
   glBindBuffer(GL_ARRAY_BUFFER, squarevbo);
   glDrawArrays(GL_TRIANGLE_FAN, 0, 4);
Most lebuktam! Nem is négyzetet rajzoltunk ki, hanem két háromszóget! A mélységi puffer használatra készen áll. Ne felejtsük el felszabadítani az erőforrásokat kilépésnél!

Szólj hozzá!

Címkék: programozás demoscene opengl

Nagy fájlok mozgatása

2011.10.19. 14:18 Travis.CG

Amikor készülünk egy release-t kiadni, gyakran kell nagy fájlokat cserélgetni a csapat tagjai között. A félig kész produkciót videóba szoktam elmenteni és úgy küldöm el a grafikusnak, hogy ő is megnézze, hol tartok. A modellek, textúrák is ritkán férnek el egy levél csatolmányként.

Szerencsére van óriáslevél küldés egyes levelező szolgáltatóknál, van webes nagy fájl küldési lehetőség és ingyenes tárhelyek. Mindegyiknél van bizonyos korlátozás, amit természetesen pénzért fel lehet oldani.

Eddig jól megvoltunk egy 500MB-os korláttal ellátott webes fájlküldő szolgáltatással. Egészen addig, míg az ingyenes, regisztrációtól mentes szolgáltatás korlátozását le nem csökkentették 250MB-ra. Szóba jöhetett volna, hogy másik szolgáltatót keresünk, de bennem van egy félsz, hogy az ingyenességnek ára van, amit spamban mérnek. (Meg felugró reklám ablakokban, amit szintén utálok)

Tehát továbbra is ott a kérdés, hogyan küldjünk egymásnak nagy fájlokat ingyen, miközben e-mail címünket sem terjesztjük net-szerte.

A megoldás az, ha közvetlenül össze tudnánk kötni a gépeinket. Ez sok szolgáltatónál gond lehet, ahol a szerződés kimondja, hogy nem lehet szervert üzemeltetni. Én nem is bátorítok senkit erre. De kb. 10 percre meg lehet nyitni egy SSH portot, hogy kicseréljük egymás között az adatokat.

Először is kell egy számítógép, amin elindítjuk az SSH démont. Létre kell hozni egy új felhasználót, annak jelszót vagy kulcsot adni, amivel eléri a gépünket. A tűzfalon nyitni kell egy portot, amin fogadjuk a kapcsolatot. Ha bátrak vagyunk, ez lehet a 22-es port, ami az alapértelmezett SSH port, de választhatunk magasabbat is.

Az ismerősünknek elküldjük az ip címünket, a felhasználói nevet és jelszót. Ő belép, feltölt, letölt, majd kilép. A módszer hátránya, hogy ugyan abban a pillanatban mindkettőnknek ott kell ülni a gép előtt, vagy legalábbis bekapcsolva kell lennie a gépnek.

Mivel nekem több gépem is a netre van kötve, van egy routerem, ami kicsit több munkát ígér, de cserébe nagyobb kényelmet is biztosít.

Először is van benne egy olyan lehetőség, hogy a mindenkori dinamikus ip címet fel tudja tölteni a dyndns-re. Ezzel elérhetjük, hogy a mindenkori ip cím helyett egy könnyen megjegyezhető url-t adhatunk meg, ami nem fog változni. Ingyenes regisztrációval egy ip címhez rendelhetünk nevet, ami magánfelhasználónak bőségesen elegendő. A router adminisztrációs felületén meg kell adni a regisztrált nevet, a felhasználói nevet, valamint a jelszót.

A routernek ezután be kell állítani, hogy a bejövő kapcsolatot melyik géphez, annak melyik portjára irányítsa (port forwarding). Ezért a gépeim mind statikus IP-vel vannak ellátva.

Így ha fájlokat kell cserélni, csak megbeszélünk egy időpontot. A gép bekapcsolása után a router fellövi az ip-t a dyndns-re. Az ismerősünk becsatlakozik és míg a fájlok róják hosszú útjukat, addig egy csevegőprogrammal megbeszélhetjük a részleteket. Nincs spam, nincs felugró reklám. A sebesség a szolgáltatóktól függ.

A másolás végén én lezárom a portot, ezzel is csökkentve a támadható felületet és kikapcsolom a gépet.

Szólj hozzá!

Címkék: biztonság rendszergazda

Villanybojler szerelés

2011.10.09. 21:44 Travis.CG

Vannak alkalmak, amikor minden összejön. A sürgős munka, ami miatt hétvégén is dolgozni kell, az igéret, hogy weboldalt fejlesztek és a bojler elromlása. A teendők gyors prioritizálása után a bojler javítása mellett döntöttem.

A jelenség az volt, hogy a bojler alján folyt ki a víz. Az áramot gyorsan lekapcsoltam, majd elkezdtem leereszteni a vizet a kis szelepen keresztül. Naívan azt gondoltam, ha már úgyis le kell ereszteni a vizet, akkor a kifolyó vízben mindjárt megfürdök, nehogy kárba vesszen az a sok meleg víz. A leeresztés hatására nagyjából 20 liter folyt ki, ami még ahhoz is kevés volt, hogy a lábamat rendesen megmossam. De hol van a többi 100 liter?

Mivel még soha nem szereltem bojlert, elérkezettnek láttam az időt, hogy ebbe is belekóstoljak. A netes forrásokat gyorsan átnézve azt láttam, hogy valószínűleg túl sok a vízkő, ami felforrósodva tönkretette a tömítést a bojler alján. Mivel már két éve nem tisztítottam ki, ennek igen nagy volt az esélye. A javítása nem foghat ki rajtam, gondoltam szombat este.

Az elektronika eltávolítása előtt fényképeket készítettem a még összeszerelt állapotról, hogy lássam a fekete drótok merre mennek. Ez a későbbi összeszerelésnél nagyon hasznosnak bizonyult.

A szétcsavarozás könnyen ment. A fenéklemez eltávolításánál viszont hiába lazítottam a csavarokat, a lemez úgy tapadt, hogy ellenállt a vízkő súlyának, és még kb. 100 liter víznyomásnak. Visszacsavartam a csavarokat, majd szépen óvatosan elkezdtem lefeszegetni a fenéklemezt. A víz végre elkezdett távozni a rendszerből, a folyás mértékét pedig szabályozhattam a csavarokkal.

Mivel elég lassan eresztett a bojler, ezért addig elmentem befejezni a munkahelyi munkákat és csak néha néztem rá, hogy a víz távozása megfelelő-e. Egy óra múlva le is vehettem a fenéklemezt. Ezt láttam:

A kép címe a régi vicc is lehetne: "Kapard fiam, ott lesz valahol a póló is!".

Az anód eltörött, annyira el volt vékonyodva. A helyzet nem volt jobb a tartály belsejében sem. Összesen ennyi vízkövet kapartam ki belőle:

Mivel nem volt tartalék alkatrészem, ezért abba is hagytam itt a szerelést. Vasárnap reggel korán felkeltem és elindultam egy másik városba, ahol biztos voltam, hogy egy nagy áruház nyitva van. Abban már kevésbé voltam biztos, hogy alkatrészeket is fogok kapni. A félelmem alaptalan volt. Vettem egy új fenéklemezt, fűtőszálat, tömítést és anódot. A kincsekkel hazatérve nekiláttam az összeszerelésnek.

A fenéklemez visszahelyezése volt a legmacerásabb. A csavarok ugyanis egy kis fülön lógnak. Mikor hozzájuk ért a fenéklemez, néha leugrottak a fülről és nagyot csattanva a kádban landoltak. Ha a csavarokat először a fenéklemezbe raktam, akkor meg nem tudtam a fülekre rakni őket. Végül nagy ügyességgel mégis valahogy felhelyeztem és átlósan elkezdtem megszorítani az anyákat, hogy egyenletesen legyenek terhelve. Mikor minden a helyén volt, egy kicsit megnyitottam, hogy megnézzem, mindenhol jó-e a szigetelés.

Nem volt. A fűtőszálnál folyt a víz. Számba vettem, mit raktam be és mit nem. Lehet, hogy oda is kell valami tömítés? A neten rákeresve kiderült, igen, oda is kell tömítés. Akkor ismét felkerekedtem, hogy másodszor is elmenjek egy másik városba alkatrészért. A vonaton már törzsutas leszek. A nagy áruháznál viszont pont a fűtőszál tömítésből készlethiány volt. Abban reménykedtem, hogy vasárnap este már lesz melegvíz, de csalódnom kellett. Az este hátralevő részében befejeztem a melóhelyi feladatokat és a weboldallal is játszottam kicsit.

Másnap reggel elmentem egy kb. 200 méterre lévő szerelvény üzletbe és megvettem a tömítést. Az ára harmad annyi volt, mintha egy nagy barkácsáruházban vettem volna. Nem akartam felhúzni magam, ezért nem kérdeztem meg, hogy a többi alkatrész mennyibe került volna. Otthon összeszereltem mindent. Megpróbáltam visszahelyezni a fenéklemezt, de a fűtőszál nem fért be a bojlerbe. Sikerült fordítva összeraknom! Ismét szétbontottam, majd összeszereltem. Megfogadtam, hogy szerzek egy villáskulcs készletet, mert a Multitoolból kialakítható fogó jó, de nehezebb jól megszorítani az anyákat vele. Összeszereltem. Tartottam egy nyomáspróbát. A víz sehol nem szökött, aminek nagyon örültem.

A korábban készített fotók alapján visszakötöttem az elektronikát, majd lélegzet visszafojtva vártam, hogy életre kelljen. Mikor a piros lámpa világítani kezdett, akkor tudtam, hogy győztem.

Szólj hozzá!

Címkék: barkácsolás

NewTech meetup

2011.10.07. 23:33 Travis.CG

Megnéztem egy NewTech meetupot. Mint bioinformatikust elsősorban a biohacking érdekelt. Az előadó arról beszélt, hogy az olcsó vegyszereknek és az OpenPCR-nek, ingyenes bioinformatikai programoknak hála bárki megvizsgálhatja környezetét. Úgy is mondhatnám egy biológus szemével nézheti a világot. Példaként említette, hogy egyes emberek az étteremben felszolgált hal genetikai markereit keresték, hogy megtudják, tényleg azt adtak-e nekik, amit ők megrendeltek.

Mint olyan ember, aki már dolgozott laborban, azt tudom mondani, hogy sajnos ez nem ilyen egyszerű. Ha már van tiszta DNS, akkor tényleg lehet vele "játszani", de a DNS tisztítása, kinyerése egyáltalán nem olcsó. Ember esetében lehet venni DNS izoláló kiteket, amelyek bárkit bűnügyi helyszínelővé változtatnak, de ezek egyáltalán nem az olcsó kategóriába esnek. Ha pedig olyan fajokat akarunk megszekvenálni, ahol bejáratott protokol sincs, akkor több, erősen mérgező vagy rákkeltő anyaggal kell dolgozni. (Egy ismerősöm például egy gyógynövényből igyekszik DNS-t izolálni. Mesélte, hogy nem könnyű a dolga, pedig ő egy jól felszerelt laborban próbálja mindezt)

Egy másik előadás már valódi hackerekről szólt, akik tudásukat biztonságos környezetben gyakorolhatják. Olyan weboldalak ezek, amik rejtvény formájában egyre nehezebb feladat elé állítják a potenciális hackert. A több, különböző oldalon elért pontszámok összegyűjtésére szintén született egy weboldal, ahol mindenki megtudhatja, mennyit is ér.

Ami még tetszett nekem, az egy olyan videó volt, ahol történészek egy játék motort felhasználva a Mohácsi csatáról készítettek filmet. Azon gondolkodtam, mennyire lenne nehéz olyat csinálni, hogy "élőben" kövesség az eseményeket? Úgy képzelném el a dolgot, mintha szellemek lennénk, akik repülve oda mennénk a csata közben, ahova akarunk. A játékmotor elvileg lehetővé tenné ezt is.

A többi előadás nem volt érdekes.

Szólj hozzá!

Címkék: életmód

Geneious: Szép vagy okos?

2011.10.02. 15:46 Travis.CG

Nem szívesen dolgozom CLC-vel. Csak akkor indítom el, ha kiosszák feladatban, hogy az adott problémát ezzel kell megoldanom. Azért nem szeretem, mert nem képes vizualizálni az információt. Amit vizualizál, az pedig ronda, nehezen kezelhető.

Nemrég viszont megkértek, hogy nézzem meg a Geneious programcsomagot, ami egyfajta CLC Workbench rivális. Megpróbálom bemutatni, hogy egy újgenerációs szekvenciákkal foglalkozó bioinformatikus munkáját miként tudja segíteni. Teljesítményre és pontosságra nem fogok kitérni ebben az összehasonlításban. Esetleg ha érdekel valakit, akkor szentelek ennek is egy posztot. (Az olvasók számát elnézve erre nem sok esély van :-)

Először is, a Geneious megpróbálja csak azokat az eszközöket a kezünk ügyébe helyezni, amire éppen abban a pillanatban szükségünk lehet. Ez nagyon szimpatikus tulajdonság. Ha megnyitunk egy szekvenciát, a felső sorban megjelennek a primer tervezés és az annotáció hozzáadása gombok. A kezelőfelület ezért zsúfoltnak hat, amit én személy szerint nem tartok hátránynak.

Az információk is szépen vannak megjelenítve. Egyszerűen jó ránézni például az alternatív transzlációt megjelenítő ablakra. A fejlesztők nagy hangsúlyt fektettek a legkülönbözőbb adatbázisokhoz való kapcsolódásra. Példának okáért egy nyilvános EnsEMBL adatbázishoz próbáltam meg kapcsolódni a segítségével. Ha az egyéb járulékos elemeket telepítettem volna, minden bizonnyal sikerült volna. Ez nem a program hibája.

A menüsorban is csak azok az elemek aktívak, amelyek relevánsak a kijelölt adattípus feldolgozása szempontjából.

Rengeteg adattípust képes importálni. Sajnos itt komoly hiányosságok vannak. Először is, nincs finomhangolásra lehetőség. Aki dolgozott már FASTQ fájllal, az tudja, hány féle variánsa van. A Geneious ennek ellenére nem kérdez semmit, csak betölti azt. Nem tudja például, hogy színkódolásos adatokat is tartalmazhat, ezért ha ilyet kísérelünk meg betölteni, nem olvas be semmit. Ugyan így nem kérdez rá a paired-end adatokra sem. Ami azt illeti, paired adatok kezelésére emiatt teljesen alkalmatlan. (Színkódolt adatokat csak csfasta formátumban tud betölteni, de én nem tapasztaltam, hogy megkérdezte volna, van-e quality fájl.)

Tegyük fel, sikeresen beolvastuk valahogy a szekvenciánkat. Mit kezdhetünk vele? Ebből a szempontból is elég kiábrándító a program. Csinálhatunk de-novo-t vagy illeszthetjük referencia szekvenciához. Nincs SNP detektálás, nincs RNA-Seq, Chip-Seq. Semmi.

A referenciához illesztés valami furcsa okból kifolyólag nem az Alignment, hanem az Assembly menüpont alatt található. Itt egyetlen dialóguspanelen választhatjuk ki, hogy milyen módon akarjuk illeszteni a szekvenciákat. Ha viszont referenciához akarunk illeszteni, akkor a referencia szekvenciát itt nem választatjuk ki! Azt azelőtt kell kijelölni, hogy a dialógusablakot megnyitnánk. Itt egy újabb probléma van. A két fájlnak ugyan abban a könyvtárban kell lennie. Én személy szerint szeretem külön tárolni a readeket és a referencia szekvenciákat. (Esetleg a referenciákat is tovább bontom olyan naív gondolatok szerint, hogy prokariótáról vagy eukariótáról van-e szó) Hiszen egy referencia fájl több különböző analízis során is felhasználásra kerülhet. A Geneious esetén el kell felejteni ezt a fajta felosztást. Ott célszerű az egy feladathoz szükséges fájlokat egy könyvtárba helyezni. Sőt nem célszerű, egyenesen kötelező.

Miután végeztünk az illesztéssel, könnyen tudjuk nagyítani és kicsinyíteni a látható képet. Görgethetünk jobbra és balra. De nem ugorhatunk referencia pozícióra. Miért? Ez egy nyilvánvaló igénynek tűnik. Tablet, IGV mind biztosít lehetőséget, hogy egy adott pozícióhoz tekerjek. A másik nagy szívfájdalmam a nem mappelt readek hiánya. Hogyan határozzam meg, hogy mennyire sikeres a mappelés, ha nem tudom, hány readet sikerült mappelni?

Van egy Text View nevű fül is, ahol a grafikus sallangoktól mentesen nézhetjük meg az eredményeket. Egészen jó, kivéve, ha túl sok adatot akarunk látni, mert akkor egyszerűen levágja azt, amit nem tud megjeleníteni. Ez többszörös illesztésnél ez 57 oszlop és 1500 szekvencia. (Én megközelítőleg 10 ezer szekvenciát illesztettem egy 12 ezer bázispár hosszú genomi szakaszhoz.) Tehát ez egy teljesen fölösleges funkció.

A Geneious jól használható lett volna 10 évvel ezelőtt, amikor még csak Sanger szekvenciákkal kellett játszadozni. Laboratóriumi munkámra visszagondolva biztosan nagyon örültem volna egy ilyen programnak. A világ viszont megváltozott. Egy bioinformatikai program nem teheti meg, hogy figyelmen kívül hagyja az újgenerációs szekvenálások igényeit. Az Emboss - az egyik kedvenc programcsomagom - fejlesztői is igyekeznek bekapcsolódni ebbe a folyamatba. Geneious így csak szép lehet, okos nem.

Szólj hozzá!

Címkék: bioinformatika

Vonalat akarok rajzolni

2011.09.29. 11:48 Travis.CG

Nem nehéz vonalat rajzolni. Vagy mégis? Mennyi kódot kell írni, hogy az ember kirakjon a képernyőre egy vonalat?

Mikor még csak C64-em volt, nem okozott gondot, hogy kirajzoljak egy vonalat. Igaz, ehhez a Simon's Basic nevű segédalkalmazás kellett, de gond nélkül meg tudtam jeleníteni, amit szerettem volna. Nem kellett hozzá voodoo mágia:

10 HIRES 0,1
20 LINE 0,0,320,200,1
Ahogy fejlődött a számítástechnika, a vonal rajzolása is egyre bonyolultabb lett. A 486-oson Turbó Pascallal már nem volt olyan egyszerű, de még belefért a keretbe. Be kellett tölteni valami meghajtót és már rajzolhatott is az ember.

Uses graph;
var grDriver: Integer;
    grMode: Integer;

Begin
  grDrive := Detect;
  InitGraph(grDriver, grMode, 'C:\BP\BGI');
  MoveTo(0,0);
  LineTo(320,200);
End.
De aki lemondott az önállóan futtatható állományok kiváltságáról, az még QBasicben is rajzolhatott.

SCREEN 13
LINE (0,0) - (320,200), 1
Utána történt valami. Megjelentek a grafikus felhasználói felületek. Ez a megállapítás természetesen történelmileg cáfolható, de az én személyes életemben így történt. Nem tudtam még akkor semmit Mac-ről, Amigáról, sem Xeroxról. Tehát megjelentek a grafikus felhasználói felületek, én pedig örültem, hogy végre talán egyszerűsödik a grafika használata, hiszen már eleve ott van.

Igaz, már nem kellett az ocsmány karakteres képernyőről átváltani a megváltást hozó grafikára, viszont kellett ablakot nyitni! Az ablak nyitása pedig nem volt olyan egyszerű. Én továbbra is csak vonalat akartam húzni, de ehhez meg kellett érteni az üzenetküldö rendszert, callback függvényeket, Windows osztályokat. Ha ezen átverekedtük magunkat, akkor lehetett vonalat rajzolni.

#include <windows.h>

LRESULT CALLBACK WindowProc(HWND, UINT, WPARAM, LPARAM);

int PASCAL WinMain(HANDLE hInstance, HANDLE hPrevInstance, LPSTR lpCmdLine, int nCmdShow){

   static char szNev[]="Proba";
   HWND      hwnd;
   MSG       msg;
   WNDCLASS  wndclass;

   if (!hPrevInstance) {
       wndclass.style=CS_HREDRAW | CS_VREDRAW;
       wndclass.cbClsExtra=0;
       wndclass.cbWndExtra=0;
       wndclass.hInstance=hInstance;
       wndclass.hIcon=0;
       wndclass.hCursor= LoadCursor(0,IDC_ARROW);
       wndclass.hbrBackground=GetStockObject(LTGRAY_BRUSH);
       wndclass.lpszMenuName=0;
       wndclass.lpszClassName=szNev;
       wndclass.lpfnWndProc=WindowProc;
       RegisterClass(&wndclass);
   };

   hwnd=CreateWindow(szNev,
    "Proba Ablak",
    WS_OVERLAPPEDWINDOW,
    CW_USEDEFAULT,
    CW_USEDEFAULT,
    CW_USEDEFAULT,
    CW_USEDEFAULT,
    0,
    0,
    hInstance,
    NULL);

   ShowWindow(hwnd,nCmdShow);
   UpdateWindow(hwnd);

   while (GetMessage(&msg,0,0,0)){
      TranslateMessage(&msg);
      DispatchMessage(&msg);
   }

   return msg.wParam;
}

LRESULT CALLBACK WindowProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam){
   HDC hdc;
   PAINTSTRUCT ps;

   switch (message){
      case WM_PAINT:
        hdc=BeginPaint(hwnd, &ps);
        MoveTo(hdc, 0, 0);
        LineTo(hdc, 320, 200);
        EndPaint(hwnd, &ps);
      return 0;
      case WM_DESTROY:
        PostQuitMessage(0);
      return 0;
   }
   return DefWindowProc(hwnd, message, wParam, lParam);
}
Mikor először használtam Visual Basicet (4.0), akkor egy pillanatra hatalmas kő esett le a szívemről. Először tudtam úgy rajzolni, hogy nem kellett a Windows lelki világával foglalkozni. Csak húztam egy ablakot és még a print üzenetek is megjelentek rajta! Felemelő érzést volt, még akkor is, ha a végleges futtatható fájlok mellé vb40016.dll-t kellett csomagolni (A példaprogram csak az ablak aktiválásánál használt szubrutint tartalmazza, valójában kicsit több sorból áll a forráskód).

Private Sub Form_Activate()
Line (0,0) - (320,200), 1
End Sub
A Delphi már normális exe-t készített. Adott Canvas objektumot. Azzal is lehetett rajzolni, de már nem volt az az egyszerű eset, mint a Visual Basic (a kód itt is csak egy részletet tartalmaz).

procedure TForm1.FormActivate(Sender: TObject);
begin
  Canvas.MoveTo(0,0);
  Canvas.LineTo(320, 200);
end;
Utána ismerkedtem meg a Linux-szal. Mintha visszafordult volna az idő! Az svgalib segítségével konzolból tudtam vonalakat feszíteni két pont közé, akár csak Turbo Pascalban. Cserébe root-nak kellett lennem, ami tudjuk mit jelent Linux alatt. A későbbi svgalib helper modul igyekezett javítani a helyzeten.

#include <vga.h>
int main(int argc, char **argv){
  vga_init();
  vga_setmode(G320x200x16);
  vga_setcolor(4);
  vga_drawline(0,0,320,200);
  vga_setmode(TEXT);
}

Pusztán az X-et használni rajzolásra, őrültség. Ha a Windows 3.1 modelljét feleslegesnek ítéltem, akkor a puszta X használata maga a tömény mazochizmus. Ha pedig GTK-t vagy QT-t használ az ember, akkor csökkenti a hordozhatóságot.

Néha az is megesett velem, hogy nem is a képernyőre kellett rajzolni, hanem egy képállományba (mondjuk mert egy weboldalhoz dinamikusan generáltam a képet). Ilyenkor a GD nevű könyvtárat használtam. A változatosság kedvéért PHP-ból:

<?php
   $p = imagecreatetruecolor(320,200);
   imagecolorallocate($p, 0, 0, 0);
   $c = imagecolorallocate($p, 255, 255, 255);
   imageline($p, 0, 0, 320, 200, $c);
   header("Content-type: image/png");
   imagepng($p);
   imagedestroy($p);
?>
Általában viszont a képernyőn akarjuk látni az eredményt, nem egy fájlban.

Az OpenGL Gluttal már egészen jó alternatíva. Legalábbis a régi glBegin-glEnd páros. Hangsúlyozom, vonal rajzolásról beszélek. Amikor a több millió poligon megjelenítésének oltárán feláldozták a gyors prototipizálás lehetőségét, ismét új alternatíva után kellett néznem.

#include <GL/glut.h>

void Display(){
   glBegin(GL_LINES);
   glVertex2f(0,0);
   glVertex2f(320,200);
   glEnd();
   glutSwapBuffers();
}

void keyfunc(unsigned char key, int x, int y){
   switch(key){
      case 27: exit(0);
   }
}

int main(int argc, char *argv[]){
   glutInit(&argc, argv);
   glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB);
   glutInitWindowSize(1024,768);
   glutCreateWindow("Vonal");

   glutDisplayFunc(Display);
   glutKeyboardFunc(keyfunc);
   glutIdleFunc(Display);
   glutMainLoop();

   return(0);
}
Az egyik lehetőség a Java volt. Ez a nyelv azt ígérte, hogy az egy vonalas rajzprogramom platformfüggetlen lesz. Sajnos a grafika kifejezetten platformfüggő. A példaprogram egy vonal rajzoló applet, hogy minél kevesebbet kelljen írni:

import java.awt.*;
import java.applet.*;

public class Line extends Applet {
  public void init(){
  }

  public void stop(){
  }

  public void paint(Graphics g){
    g.drawLine(0,0,320,200);
  }
}
A másik lehetőség, hogy maradok Windows alatt és áttérek a C#-ra. Amit azt illeti, az Etch-a-sketch című demónkhoz C#-ban kezdtem el írni egy szerkesztőprogramot, ami a demó grafikáit készítette volna el. Érdekes módon ez a demó is főleg vonalakból áll.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace drawing
{
    public partial class Form1 : Form
    {
        Graphics Canvas;
        Pen drawpen;

        public Form1()
        {
           InitializeComponent();
           Canvas = this.CreateGraphics();
           drawpen = new Pen(Color.Black);
        }

        private void Form1_Activated(object sender, System.EventArgs e)
        {
           Canvas.DrawLine(drawpen, 0,0, 320, 200);
        }
    }
}

A példa itt is csak egy részletet mutat be abból, ami a vonal rajzoláshoz kell. Lehet látni, hogy a példák legtöbbje nem is a grafikáról szól, hanem egyéb járulékos elemekről, amelyek nélkül a grafikus felületen nem tudunk pixeleket színezni.

Mit is akarok? Vonalat húzni, gyorsan, eszközfüggetlenül. Ahogyan Perl alatt villám sebességgel feldolgozom a szöveges állományokat, úgy akarom egy ablakban megjeleníteni a vonalaimat. Szeretném, ha ez platform független lenne. Van remény? Igen van. Úgy hívják Processing. Végre tudok vonalat rajzolni.

void setup(){
   size(320,200);
}

void draw(){
   line(0,0,320,200);

Frissítés:

Persze a Python is tartalmaz ügyes modulokat:

import Image
import ImageDraw

image = Image.new('RGB', (1024, 768)) # width and height
draw  = ImageDraw.Draw(image)
draw.line((0,0,1024,768), fill = (0,255,0)) # coordinates and color

 

Szólj hozzá!

Címkék: programozás filozofálás

CLC parancssorból

2011.09.28. 10:07 Travis.CG

A klikkelős programokkal az egyik alapvető problémám, hogy csak nagyon ritka esetben nyújtanak segítséget az ismétlődő feladatok leeegyszerűsítésére. Emlékszem, még a win 3.1-ben voltak makrók, amelyekkel több-kevesebb sikerrel lehetett felvételeket készíteni tevékenységünkről, majd visszajátszani. A módszer sikertelenségét jól mutatja, hogy ez az eszköz már nem része az újabb rendszereknek.

A különböző makronyelvek és azok programba/szkriptbe szervezése ellenben virágzik, gondoljunk csak a Blenderre, amiről már röviden írtam. A bioinformatikában különösen fontos, hogy több adattal dolgozzunk. Ritkán van olyan szerencsénk, hogy egy mintát kell elemeznünk. A folyamatok automatizálása ezért létkérdés.

A CLC is felismerte, hogy hiába a könnyű kezelhetőség, a szupergyors algoritmusok, ha egyszer a felhasználó klikkelési sebessége limitálja az adatfeldolgozás hosszát. Ezért a CLC Server kapott egy parancssoros, jelenleg béta állapotú felületet. Mivel bétáról van szó, lehetnek eltérések az itt leírtakhoz képest.

Használat

A parancssor egyetlen Java alapú program, ami a clcserver nevet kapta. Az összes programozói eszközt az operációs rendszer parancsértelmezője adja, ami az itt bemutatott példáknál egy Linuxos Bash lesz. Érdemes megemlíteni egy másik programot is, a clcresultparser-t, ami a program által visszaadott szöveges eredményt dolgozza fel. Ha elég erőt érzünk magunkban, helyettesíthetjük egy grep-el.

A program működéséhez indítsuk el a CLC Servert:

>CLCGenomicsServer start

Most már nyugodtan használhatjuk a szkriptjeinket.

Kötelező argumentumok

Az első kényelmetlenség, hogy minden egyes parancs kiadásához négy állandó paraméter kell. Mivel szerverről van szó, ez a szerver URL-je (-S), a port (-P), felhasználó név (-U), jelszó (-W).

>clcserver -S localhost -P 1234 -U user -W secretpassword

Ennek nyugodtan csinálhattak volna egy konfigurációs állományt. Mivel nem csináltak, hozzunk létre egy Bash változót és nevezzük el CMD-nek. A továbbiakban csak a CMD változóra fogok hivatkozni:

CMD="/opt/CLCServer/CLI/clcserver -S localhost -P 1234 -U user -W secretpassword"

Elérési utak

Mivel szerverről van szó, és a parancssoros programnak nem kell feltétlenül azon a gépen futnia, a fájlok elérése URL-en keresztül történik. A protokol a clc. Ha olyan fájlra akarunk használni, ami már a CLC Server "látókörében" van, akkor a clc://server kezdetű URL-el tudunk rá hivatkozni. (Ezek clc kiterjesztésű fájlok. Szerializált Java objektumok.) Ha egy külső fájlt akarunk megadni, akkor a clc://serverfile előtaggal érhetjük el azt.

Parancsok

A parancsokat a -A argumentummal adhatjuk meg, majd ezt követik a parancs-specifikus egyéb paraméterek. Például listázzuk ki azokat a fájlokat, melyek a CLC Serveren vannak:

$CMD -A ls -t clc://server/CLC -O res.txt

A -t argumentummal adjuk meg, hogy mit szeretnénk kilistázni. A -O pedig a res.txt állományba menti az eredményt. Ha megnézzük a res.txt-t, azt tapasztaljuk, hogy minden kilistázott objektumhoz tartozik két URL (egy egyszerűsített és egy teljes), egy név és dátum. Ezt a fájlt lehet feldolgozni a clcresultparser-el. Ez a teljes URL-t visszaadja. Például tegyük fel, van 23 darab "read" karaktereket tartalmazó fájlunk, amelyeket szeretnénk egy referenciához illeszteni.

for READ in `clcresultparser -f res.txt -c read`
do
  $CMD -A read_mapping --short-read-alignment-mode ALIGNMENT_LOCAL -i $READ --references clc://server/CLC/chrX -d clc://server/CLC/results
done
A -d adja meg az eredmény helyét, a --references a referencia objektum elérési útja, a -i pedig a short read adat. Figyeljük meg, hogy a clcresultparser -c opcióját, amivel kiszűrjük azokat a neveket, amelyek tartalmazzák a "read" szót.

Összegzés

A CLC jó irányba indult el a parancssoros interfésszel. Az is jó ötlet, hogy egy ismerős közegbe (Bash) beilleszhető a szervert vezérlő parancs. A használhatóságán viszont lehet még javítani. A parancsok alapértelmezett tulajdonságai is meglepően vannak beállítva, gyakran nem tükrözik a grafikus felület beállításait. (Például alapértelmezetten a short readek importjánál eldobja a read azonosítókat). Néhány esetben logikátlan opciókat is meg kell adni. (Ha nem paired adatokat töltünk be, akkor is meg kell adni a readek távolságát) Reméljük, a végleges változatban kijavítják ezeket a hibákat.

Szólj hozzá!

Címkék: programozás rendszergazda bioinformatika

süti beállítások módosítása