HTML

Az élet kódjai

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

Friss topikok

  • sdani: Oh... néha eszembe jut, hogy az EBI után esetleg vissza kellene menni valamennyire az akadémiai vo... (2025.03.18. 16:58) Pontos, jól behatárolt célok
  • legyen úgy: Szia, Értem és köszönöm a válaszodat! T. (2025.02.24. 18:23) Expose CTF
  • 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

CUDA (4. rész)

2011.02.04. 12:27 Travis.CG

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

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

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

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

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

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

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

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

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

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

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

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

}

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

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

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

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

Szólj hozzá!

Címkék: programozás

Divat és genomika

2011.02.02. 15:49 Travis.CG

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

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

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

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

Szólj hozzá!

Címkék: életmód bioinformatika

CUDA (3. rész)

2011.01.27. 14:30 Travis.CG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}

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

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

   cudaGraphicsMapResources(1, &pointBuff_CUDA, 0);
   cudaGraphicsResourceGetMappedPointer( (void**)&ppos, NULL, pointBuff_CUDA);

   calcParticlePos<<< 1, PARTICLENUM>>>(ppos);
   cudaGraphicsUnmapResources(1, &pointBuff_CUDA, 0);

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

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

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

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


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

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

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

   initOpenGL();

   glutMainLoop();

   return(0);
}

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

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

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

Szólj hozzá!

Címkék: programozás

GLX és OpenGL 4.1

2011.01.23. 21:47 Travis.CG

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

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

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

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

#define WIDTH 1024
#define HEIGHT 768

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

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

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

   int isrunning = 1;

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

   /* Other OpenGL related initialization stuff here */

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

      /* OpenGL drawing stuff here */

      glXSwapBuffers(display, window);
   }

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

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

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

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

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

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

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

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

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

gcc -lX11 -lGL test.c -o test

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

Szólj hozzá!

Címkék: programozás demoscene opengl

Szakmák, amikhez mindenki ért: Gyógyászat

2011.01.18. 11:16 Travis.CG

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

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

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

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

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

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

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

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

Szólj hozzá!

Címkék: életmód

Dalban mondom el

2011.01.16. 10:10 Travis.CG

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

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

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

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

Szólj hozzá!

Címkék: demoscene

CUDA (2. rész)

2011.01.13. 15:37 Travis.CG

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

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

A tesztprogramunk a következő:

 #include <stdio.h> #define SIZE 3000

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

   printf("Memoria foglalas GPU\n");

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

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

      error = cudaFree(gpustuff);

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

   }

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

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

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

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

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

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

Szólj hozzá!

Címkék: programozás

CUDA (1. rész)

2011.01.09. 10:00 Travis.CG

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

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

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

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

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

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

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

Kiegészítés:

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

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

Szólj hozzá!

Címkék: programozás

Táncoló árnyak

2010.12.16. 15:50 Travis.CG

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

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

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

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

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

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

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

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

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

Szólj hozzá!

Címkék: irodalom

GATK variáció analízis

2010.12.08. 10:05 Travis.CG

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

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

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

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

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

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

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

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

Szólj hozzá!

Címkék: bioinformatika

SSH alagút kicsit bonyolultabban

2010.12.01. 20:26 Travis.CG

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

A belépés valami ilyesmi volt:

local> ssh gate

gate> ssh barrier

barrier> ssh storage

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

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

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

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

localhost> ssh -N -f -q gate

localhost> ssh -N -f -q barrier

localhost> ssh storage

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

Szólj hozzá!

Címkék: biztonság rendszergazda

UTGB genom böngésző

2010.11.24. 13:54 Travis.CG

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

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

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

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

Szólj hozzá!

Címkék: bioinformatika

EnsEMBL weboldal telepítés

2010.11.19. 13:19 Travis.CG

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

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

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

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

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

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

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

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

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

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

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

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

Szólj hozzá!

Címkék: cloud computing bioinformatika

Amazon és a biztonság

2010.11.17. 15:20 Travis.CG

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

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

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

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

w00tw00t.at.blackhats.romanian.anti-sec

 

Szólj hozzá!

Címkék: biztonság cloud computing

Bioscope

2010.11.03. 10:38 Travis.CG

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

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

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

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

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

Szólj hozzá!

Címkék: bioinformatika

Aeronautism

2010.10.29. 11:35 Travis.CG

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

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

Szólj hozzá!

Címkék: demoscene

Gondolatok a kézmosásról

2010.10.25. 10:36 Travis.CG

A mai nap kézmosási műveletei közben egy kolléga a következő megjegyzést tette:

- Tudtad, hogy a meleg víz bezárja a pólusaidat?

Mivel a szépészeti műveletek teljesen hidegen hagynak, azt válaszoltam neki, hogy nem tudtam.

- Ha meleg vízben mosol kezet, a bezáródott pólusokban ott maradnak a baktériumok.

- Te meg tudtad, hogy a hideg vízben kevésbé hatékony a szappan? - dacból mondtam, mintegy visszavágásként.

- Beszéld meg az orvosoddal.

Gyors információ szerzés a gugli után azt hozta ki, hogy a meleg víz pont, hogy tágítja a bőrpólusokat. Ami - nyugodt körülmények között végiggondolva - logikus is. A kérdés, ami felmerült bennem, honnan származott kollégám hamis információja, és mi viszi rá, hogy másoknak is ezt terjessze? Nyilván ő hisz benne, én pedig nem, de nem a valóság tartalma miatt, hanem azért, mert úgy éreztem "beszól" nekem, amitől autómatikusan ellenkező véleményre álltam át. Sőt, információt szereztem arról, hogy nekem van igazam, neki nem.

Tovább gondolva: Vajon hány olyan tudást birtokunk, ami nem tényeken, hanem személyes érzéseken alakul? Van rá egy másik példám is. Az egyik asszisztens kérte, hogy segítsek neki olyan tudományos cikkeket keresni, ami arról szól, hogy a tej ártalmas. Mivel én nagyon szeretem a tejet, megkérdeztem, hogy miért keres ilyesmit.

- A fiam annyi tejet iszik, hogy már rosszul vagyok tőle.

Tehát nem akarta, hogy a fia tejet igyon, ezért "tudományosan" alátámasztva meg akarta mutatni, hogy az nem jó, még abban az esetben is, ha esetleg tízszer annyi irodalom szól arról, hogy a tej jó. Ha már egy cikket talált volna, már igazolja is az érzéseit.

Kérdem én, mit tekinthetünk tisztán látásnak? Mikor mondhatjuk azt, hogy objektíven szemlélünk egy kérdést, ha már olyan egyszerű ügyekben is, mint a kézmosás, ennyire az érzelmek dominálnak?

Talán nem is kell mást tennünk, mint meghallgatni a másik véleményét, és azt mondani: igazad van, ha egy kicsi bizonytalanságot is érzünk.

Szólj hozzá!

Címkék: életmód filozofálás

Hogyan botránkoztassuk meg családunkat

2010.10.21. 10:45 Travis.CG

Gyakorlati útmutató adok azoknak, akik túl nyugodt, kiegyensúlyozott életet élnek, hogyan tegyék változatossá családi életüket, miként lendüljenek túl azokon a pillanatokon, amikor egy-egy beszélgetés elakad, mert nem tudjuk, mi újat mondhatnánk. Az itt vázolt módszer ahhoz is remek segítség, hogy két ellenséges családtagot kibékítsünk, mintegy új ellenséget teremtve nekik általunk.

1. Lépés: Keress hobbit.

Ez talán elsőre könnyűnek tűnik, de nagyon megfontoltnak kell lennünk. Nem választhatunk közismert, elfogadott hobbikat, melyek akár még érdekelhetnek is másokat környezetünkben. Azzal sem elégedhetünk meg, ha csak udvariasan hallgatják mondandónkat eljövendő szenvedélyünkről, mit sem fűzve a hallottakhoz. Ez csak azt mutatja, hogy szeretünk különcködni. A különcöket megtűrik, esetleg pajkosan összepillantanak a hátunk mögött, jelezve, hogy ők nem különcök. A mi célunk nem ez. Ezért olyan hobbit kell választani, ami első hallásra is a "Minek?" kérdést váltja ki mindenkiből, akibe egy kicsi jóérzés is szorult és "Ez baromság!" felkiáltást a kevésbé toleránsokból. Ilyen lehet például a legózás (szigorúan 30 év felett!), helikopter modellezés, esetleg mások által teljesen ismeretlen számítógépek gyűjtése.

2. Lépés: Spórolj.

A spórolás teljesen elfogadott a mai világban. Mást sem hallani, mint tudatos vásárlást, környezettudatosságot és egyéb zöld/öko címszavakat. Ezekkel nincs is semmi baj. Nekünk viszont ennél tovább kell menni. Prédikációkat előadni az olcsóbb margarinról, alig világító égőket beszerezni, hogy csökkenjenek az energiaköltségek. Régi termékek cseréje esetén a "Jó az még" választ adni. Ez egy nehéz szakasz. Családunk tűrőképességétől függően jó sokáig kell húzni ezt az időszakot. Közben igyekezzünk minél több pénzt felhalmozni.

3. Lépés: Költekezés.

Eljött a nagy nap! Most az összes spórolt pénzt el kell költeni az adott hobbi egy nélkülözhetetlen elemére. Legózók esetén ez egy motorizált AT-AT lépegető, helikopterezőknél egy T-Rex 900, számítógépgyűjtőknek egy AmigaOne X1000. Az sem baj, ha több pénzt áldozunk rá, mint amennyink van. Ne döntsük a családi költségvetést nagy adósságba, de ha csak szűkösen bírjuk ki a hónap végéig, az elég a siker érdekébe.

4. Lépés: Sztoikus nyugalommal hallgatni a család dühkitörését

Igény esetén a 2-3 lépések megismételhetőek, de ekkor készüljünk fel, hogy a 4. lépés meghatározatlan időközönként újra bekövetkezik. Később, ha elég ügyesek leszünk, viszonylag drága, de apróságnak tűnő tárgyakkal járulhatunk hozzá a hobbinkhoz (például új rotorlapátok, minifig készletek).

Szólj hozzá!

Címkék: életmód

EnsEMBL telepítés a felhőre

2010.10.20. 12:57 Travis.CG

Korábbi bejegyzésemben arról panaszkodtam, hogy az Amazon Cloudon csak az ember adatait tette fel az EnsEMBL, abból is egy régi verziót. Örömmel közölhetem, hogy ez nem igaz. A teljes adatbázis fent van MySQL és Fasta formátumban.

Mostani írásomban arra akarok kitérni, hogyan lehet feltelepíteni ezt az adatbázist saját instance-ra. Első lépésként indítsunk el egy Amazon virtuális gépet. Mivel én GNU/Linux rendszert használok, a továbbiakban erre térnék ki. Első lépés, hogy telepítsük a MySQL-t, Perl-t. Ha az Olvasóim olyan kényelmesek, mint én, akkor egy Ubuntu alatt az apt-get/aptitude parancsokkal bűvészkednek, ha pedig nálam ügyesebbek, akkor forráskódból telepítik azt tetszőleges disztribúció alatt ;-)

Ha Elasticfox Mozilla bővítménnyel vezérlik a virtuális gépeket, akkor a Volumes and Snapshots fülön, a Saved Snapshots táblázatból kiválasztják a kívánt EnsEMBL adatbázist. Jelen esetben EnsEMBL 59 MySQL-t és jobb egérgomb segítségével létrehoznak egy kötetet (volume) belőle. Ez amolyan virtuális háttértárólónak fogható fel. Ha megjelenik a Created Volumes listában, akkor kapcsoljuk hozzá a futó gépünkhöz. (Figyelem! A kötet és a gép legyen azonos zónában, különben nem kapcsolhatóak össze) Adjunk meg egy eszköz nevet (jelen esetben ez a /dev/sdd lesz).

Jelentkezzünk be a virtuális gépbe ssh-n keresztül. A következő paranccsal hozzunk létre egy könyvtárat és csatoljuk be a korábban létrehozott kötetet:

sudo mkdir /ensembl
sudo mount /dev/sdd /ensembl

Természetesen a jogok beállításáról se feledkezzünk meg. Az ensembl könyvtárban ott a teljes MySQL struktúra. Most már csak az adatbázis kezelőnek kell megmondani, hogy hol találja a fájlokat. Az ensembl könyvtárban mindennek adjunk mysql tulajdonosi jogokat.

sudo chown -R mysql:mysql /ensembl

Hozzuk létre az adatbázisokat. Az EnsEMBL ugyanis minden egyes fajnak egy adatbázist hoz létre. A könyvtárat elnézve ez jó sok adatbázis, ráadásul olyan vicces neveik vannak, mint spermophilus_tridecemlineatus_core_59_1i. Utálok sokat gépelni, ezért a következő módon hozom létre az adatbázisokat:

cd /ensembl
ls | awk '{print "create database "$1";"}' >~/createdb.sql

Majd beletöltöm az adatbázisba:

mysql -u root <~/createdb.sql

Most jön a trükk. A /var/lib/mysql-ben vannak a létrehozott adatbázisok. (Kivéve, ha valaki nagyon profi és máshova tette, de az úgyis tudja, hol keresse) Meg is nézhetjük őket. A sok sudo gépelését kezdem unni, ezért root leszek. (sudo su, de gondolom ezt már mindenki tudja).

Kitörlöm a könyvtárakat, amiket fáradságos munkával létrehoztam.

cd /ensembl
for i in *; do rm -fr /var/lib/mysql/$i; done

Ezután hozzunk létre symlinkeket és állítsuk be a jogokat.

cd /ensembl
for i in *; do ln -s /ensembl/$i /var/lib/mysql/$i; chown -h mysql:mysql /var/lib/mysql/$i; done

Ennyi. A rendszer működik. Illetve mégsem. Ha bármi miatt nem megy a fenti módszer, akkor a jogosultságok tájékán kell keresni a megoldást. Amikor próbálgattam a módszereket, sokszor a következő hibaüzenettel találkoztam:

ERROR 1018 (HY000): Can't read dir of './homo_sapiens_core_59_37d/' (errno: 13)

A mysql nem tudott belépni a könyvtárba. Fórumokat olvasgatva a következő megoldások segítenek:

1) A szülő könyvtárnak is mysql tulajdonában kell lennie.

2) Legyen bekapcsolva a have_symlink (kövesse a linkeket)

3) Ubuntu alatt az apparmornak be kell állítani, hogy olvashassa azt a könyvtárat is, ahova áthelyeztük az adatbázis fájljait. Ezt röviden be is mutatom, mert az Ubuntu nagyon népszerű, talán többen belefuthatnak a hibába. (forrás)

Az /etc/apparmor.d/usr.sbin.mysqld fájlt szerkesszük, adjuk hozzá a következő sorokat:

/ensembl/ r,
/ensembl/** rw

(természetesen a kapcsos zárójelen belül). Indítsuk újra az apparmort (sudo service apparmor restart) és minden megjavul.

 Most hozzunk létre egy mysql felhasználót, és adjuk meg neki a megfelelő jogokat, hogy használhassa az adatbázist.

mysql -u root

create user 'ensembl'@'localhost' identified by 'ensembl'

Emlékezünk még a createdb.sql fájlunkra? Használjuk ismét, hogy jogokat adjunk az első felhasználónak:

sed 's/;//' createdb.sql | awk '{print "grant select on "$3".* to '"'"'ensembl'"'"'@'"'"'localhost'"'"'; "}' >grant.sql

Az idézőjelek kicsit ilyesztőek lehetnek. Ha ezzel megvagyunk, nincs más dolgunk, mint beadni a mysql-nek, a korábban leírt módon.

A következő lépés, hogy Perl API-t telepítsük.

Először a Bioperl csomagot telepítsük. Adjuk ki a sudo cpan parancsot. Ez elindítja a telepítő scriptet. Adjuk ki az install Bundle::BioPerl parancsot. Ha nem tudjuk, milyen válaszokat adjuk a kérdésekre, akkor az enter megnyomásával léphetünk tovább. Ezzel nagy hibát nem követünk el.

A BioPerl csomag telepítése után következik az EnsEMBL perl csomagok telepítése. Én itt el szoktam térni az általánosan elfogadott telepítési módszertől, mert én a modul könyvtárat egyszerűen bemásolom a többi Perl modul közé.

Tehát kicsomagolom a Perl modulokat a jó öreg tar -xfz -vel, majd a modules könyvtár teljes tartalmát átmásolom pl. a /usr/lib/perl5 könyvtárba. (Vagy más perl5 modul könyvtárba, ahol megtalálható a Bio névteret jelölő könyvtár) Az EnsEMBL moduljai nem fognak felülírni egyetlen más modult sem. (Legalábbis nekem még nem tették)

Ha készen vagyunk, próbáljuk ki a következő rövid szkriptet, amivel ellenőrizhetjük, hogy mindent jól végeztünk:

use Bio::EnsEMBL::Registry;
use strict;

# Get all exons

my $reg = 'Bio::EnsEMBL::Registry';
$reg->load_registry_from_db(-host => 'localhost', -user => 'ensembl', -pass => 'ensembl');
my $adaptor = $reg->get_adaptor('Human', 'Core', 'Exon');
my @exons = $adaptor->fetch_all();

 

Ha hiba nélkül lefut, akkor végeztünk.

Szólj hozzá!

Címkék: cloud computing bioinformatika

Main party riport 6. rész

2010.10.07. 12:46 Travis.CG

Hazaút. A hazajutásról akár még filmet is forgathatnánk. Eredetileg
úgy volt, hogy kocsival visznek minket ki a repülőtérre, de elromlott
az egyik járgány, ezért Unreal és én kaptunk egy vonatjegyet, hogy azzal
menjünk el Villion (az elgépelésért elnézést kérek, de már nem emlékszem a
nevére) repülőterére, majd ott szálljunk át egy buszra, és azzal menjünk
Marseille-ba. A vonatra felszálltunk. Akár csak Budapesten az elővárosi
vonalakon, itt is van egy kis ledes tábla, ami mutatja, hogy melyik
állomás is jön. De még van 3-4 féle információk közöl. A célállomásunkat többször
is mutatta, amiből én arra következtettem, hogy azon keresztük fogunk menni.

Így történt, hogy fent ültünk a vonaton akkor is, amikor le kellett volna
szállni. Épp balra néztem ki az ablakon, amikor valami repülőtér szerű
képződményt láttam. Megkérdeztem Unreal-tól, nem itt kellett volna-e
leszállni. Az utasok faggatása után kiderült, hogy igen. A következő
megállónál leszálltunk. Tanácstalanul forgolódtunk az állomáson. Végül azt
javasoltam, keressünk egy taxit, majd menjünk egyenesen a Marseille-i reptérre,
mert félő, hogy lekéssük a buszt. Egy taxi jött is felénk, de integetésünkre,
nem állt meg. Unreal stoppolni próbált, de sikertelenül. Végül kerestünk
egy helyet, ahol hívtak nekünk taxit. Egy idősebb ember nyitott ajtót, akinek
elmutogattuk, hogy taxit hívjon ide. Mondtam taxi. Mutattam egy telefonálás
egyezményes jelét (hüvelykujj fülbe, kisujj a száj elé). Majd a föld felé mutattam.
Közben angolul artikuláltam. Csak négyszer kellett megismételni, mire felfogta,
hogy taxit akarunk hívni. (Nem is rossz egy embertől. - mondaná Bishop, az android)

A taxi megérkezett. Itt következett a második probléma. A Marseille-t még értette.
Azt is, hogy airport. De utána kérdezett valamit, mire mi azt mondtuk, egyes terminál.
Mutogattunk is, mert persze ő sem értett más nyelven. Ezt sem értette. Pedig a felfelé
mutató hüvelykujj gondolom elég egyezményes. (Lehet, hogy azt hitte, azt mondom,
fasza a járgányod). Valami csoda folytán mégis kiértünk a repülőtérre időben. Sajna
a csomagok miatt plusz pénzt vakart le tőlünk, pedig a taxióra kevesebbet mutatott.

A becsekkolás sem ment minden probléma nélkül. Kis autómatákkal kellett volna megoldani
a problémát, de az valahogy nem akarta az igazságot. Volt ott egy kockás inges öreg fickó,
aki rendszeresen belenyúlt folyamatba. Például az ellenőrzéshez szükséges útlevelet
forgatta el a kezemben. (Pedig jól raktam be). Az idő fogyott, ezért végül az emberi
személyzet segítségét vettük igénybe. A kockás inges férfi továbbra is ott matatott
a gépek mellett, végül mintha egy nagyot csapott volna az egészre.

A Marseille-i gép késve indult. Ennek ellenére még időben megérkezett, mert a másik
gép is késett. Ezzel nem is lett volna semmi baj, ha nem vidéken lakunk Unreallal,
és nem ment volna el az összes tömegközlekedési eszköz. Unreal végül egy kis telefonálással
kiderítette, hogy egy éjszakai járattal szolnokig el tud menni, oda pedig kijönnek érte
kocsival. Én pedig bementem a munkahelyemre, megágyaztam és másnap nagyon korán
kezdtem dolgozni.

Szólj hozzá!

Címkék: demoscene parti riport

Main party riport 5. rész

2010.10.03. 00:11 Travis.CG

A 4k intrók kellemes szórakozást nyújtottak. Rögtön az első egy procedurális
grafika volt, ami egy pouet.net oldalt jelenített meg. Eredeti ötlet. Volt
egy Chaos theory remix. A készítők a nagy sikerű 64k intrót tömörítették
még apróbbra. A jelenetek egy része nagyon hasonló a nagy előd jeleneteihez, a zene
pedig megállja a helyét. Amstradt CPC-n futó 4k is készült. A gép képességeihez
mérten igen látványos alkotás kerekedett belőle. A Rebels csapat grow up c.
intrója egy növény életét próbálja meg bemutatni. Az alkotás ötletes. Nem
a szokásos geometriai alakzatok bonyolult torzításai köszöntek vissza,
amitől az egész produkció "élővé" vált.

Hamár a mértani alakzatoknál tartottunk, az Amsterdam Cancer - Cube képviseltette
magát a stílus. Szép színek és igényes zene jellemezte. Csak egyetlen 64k intró
volt. A régi nagy hírű Razor 1911 képviseltette magát, a cracktrók stílusában.

A demóktól már nem voltam ennyire elragadtatva. Mindjárt az elején meg kell
említeni az anoxia reduxot az ASD-től. A görög csapat szemlátomást nem vitte
túlzásba a munkát. Méltán népszerű demójukat használták fel, teljesen lezanzásítva.
A zene helyett játszott zaj és a három szín a csapat programozója szerint egyfajta
művészi kiterjesztés és a tömérdek kocka forog témájú demóra adott válasz. A pouet.net-en
hosszan ecseteli demója művészi értékét és mindjárt magyarázatokat is fűz hozzá, hogy
ez vagy az a jelenet mit jelent.

Kicsit had időzzek el itt. Ha a művésznek kell magyaráznia a saját művét, akkor ott
baj van. A művész tulajdonképpen lekódolja üzenetét, amit a nézőnek kell megfejtenie.
Erre sokféle technika van, de a cél, hogy megfejthető legyen. Az más kérdés, hogy
ezek a kódok idővel változnak. Ha a mai kor műélvezője elfelejti ezt, akkor a
kritikusok/művészettörténészek segítségével támpontot kaphat, hogy ő is megismerje
az üzenetet. Természetesen az is megtörténhet, hogy a művész üzenetét csak a későbbi
korok fogják fel. Őket tekinthetjük az adott művészeti ág előre mozdítóinak. Ők
azok, akiket úgymond csak haláluk után ismernek el.

Ha valaki a demoscene-t akarja üzenetei továbbítására használni, akkor ő nem élhet
azzal a lehetőséggel, amivel egy festő. A festmény ugyanis korlátlan. Csak két szem
kell hozzá. Ellenben a demoscene feltételez egy számítógépes architektúrát, ami
óhatatlanul elavulttá válik. Éppen ezért nem használhat bonyolult kódot, hogy
majd a jövő generációja megfejti, olyat kell használnia, amit itt és most használnak.
Ha viszont a jelen nézője nem érti, akkor nem hiszem, hogy a néző a hibás, hanem a
művész, aki nem képes kifejezni az üzenetét. Azt már csak zárójelben jegyzem meg,
hogy nincs sehol sem előírva, hogy az üzenetnek nehezen emészthetőnek és érthetetlennek
kell lennie. Sajnos pont az a helyzet, hogy sokan ha számukra érthetetlen alkotással
találkoznak, azonnal úgy tesznek, mintha értenék és az egekig magasztalják azt.

De térjünk vissza a demókhoz. Navis azt mondja, hogy az Utolsó vacsorára hajazó jelenet
előtt megjelenő Happy meal szöveggel azt akarta jelezni, hogy a vallás nem segít. Én
viszont úgy értelmeztem, hogy kigúnyolja a vallást. Ki a hibás? Én, mert nem értettem
meg, vagy ő, mert nem volt képes kifejezni magát?

A többi alkotással nem volt ilyen probléma. A junkyard opera érdekes volt, de nem
az én ízlésvilágomnak való. Ennek ellenére elismerem, mint igényes alkotást. A
győztes xmen demó inkább fogható fel viccesnek, mint komolynak. Sok vidám
percet szerzett a nézőknek. A Nuance invitációja számomra csalódás volt.
Breakpointon a csapat megmutatta, hogy ők is tudnak félelmetes demót csinálni,
de ez inkább rutinból összerakott produkció. A többi nem volt számottevő.
 

Szólj hozzá!

Címkék: demoscene parti riport

Main party riport 4. rész

2010.10.02. 16:00 Travis.CG

Az előző részben nagyon elkalandoztam a város leírásával, ezért a partiról
inkább külön részben teszek említést. A szervezők mindent bevetnek, hogy jól
érezzük magunkat. Az ingyen három gombócos fagyit nyalogatva össze is
gyűjtöttem, mi mindennel kedveskednek nekünk. Először is az utazás. Ennek
költségét a parti állja. Lefoglalták a repülőre a jegyet, mikor megérkeztünk,
a partira szállítottak minket. Reggelit kapunk minden nap.

Az első compo a mash-up volt. Heten indultak. Én, aki úgy osztályozom a zenét,
hogy tetszik vagy nem (amivel azt akartam érzékeltetni, hogy nem értek hozzá),
azt tudtam megállapítani, hogy a legtöbb résztvevő mintha csak egyszerre
játszana le párhuzamosan két számot. Hiányoltam a kreatív felhasználást.
Szerencsére Slyspy ezt ellensúlyozta. Először is mennyiségi csapást mért az
ellenfelekre. Nem kettő, hanem egyenesen négy (vagy több?) zenét használt fel.
A második csapás pedig minőségi volt. Ügyesen élt az eszközökkel.

A fotók elég vegyesek voltak. Akadt közöttük professzionális műtermi fotó,
művészi minimalista, mobiltelefonos minőségű életlen makró és vicces. Adtam
be ide is egy képet. Nyilván az én tudásom nem versenyezhet a többiek
profizmusával, de nem is ez volt a célom. Készítettem egy képet, és úgy
éreztem ezt másoknak is látni kell.

Ha valaki az gondolja, hogy a képek túl széles spektrumát ölelik fel a
témáknak, akkor a grafikai versenyt még nem is látta. A kézi rajztól a három
dimenziós renderelésen át a fényképig minden volt. Ez utóbbi azért került ide,
mert az illetőnek már volt egy fényképe (amit le is adtak), és ezt is be
akarta mutatni. Grass biztos ír versenyről részletesen a scene.hu-n.

A Main party jellegzetessége a tetőre épített óriási kivetítő. A direkt erre a
kivetítőre írt demókat csak a kültérről láthatjuk. Mindenki kivonult, hogy
megnézze az alkotásokat. A legtöbb produkció nélkülözött minden kreativitást,
csak gyorsan valamit összedobtak. Pedig egy ilyen helyszín lehetőségek
garmadáját tartalmazza annak, aki ügyes. Mi megpróbáltuk ezeket
kihasználni, de még mi is csak a felszínét súroltuk. Unreal szerint mi voltunk
a legjobbak, de már tartom magam olyan vén rókának, hogy tudjam, egy jó
produkció nem jelent feltétlenül győzelmet. Ott van például a haveri ráhatás.
A Trsi hangulatos videót mutatott, ami remekül érvényesült a tetőn, még akkor
is, ha csak régi Amigás demók összeollózása.

A wild kompón volt egy Wii, egy Amstradt CPC és egy Spectrum demó, valamint
videók. Az egyik videót biztos győztesnek merem kikiáltani. Két ember
párbaját mutatja be, akik demózenéket mutatnak egymásnak, hogy a másik
kitalálja. Remek humor jellemzi, ráadásul francia alkotás (hazai pálya előnye).
Minden esélye megvan a győzelemre. Volt egy számítógépes animációs rövidfilm.
Valószínű második lesz. Itt a témát választották meg ügyesen. A többi alkotás
könnyen a feledés homályába veszhet. Következő cikkemben az intrókat és
demókat fogom bemutatni.

Szólj hozzá!

Címkék: demoscene parti riport

Main party riport 3. rész

2010.10.02. 10:02 Travis.CG

Fél tízkor ébredtem. Megfürödtem, majd az ingyen reggeli után néztem. Mivel
Franciaországban vagyunk, croassan és csokis bukta várt minket. Ellőttem
pár kockát, majd Unrealel kimentünk a városba. Erős mediterán hatás
érvényesül az egész városon. A fő látnivaló egy római kori aréna,
ahol bikavialdalokat is rendeztek. Ennek állít emléket a milliónyi bika plüs
az ajándékboltokban, a bikás pólók tömege és a torreádorok hősiességét
bemutató festmények.

Van Gogh is itt élt, de a róla elnevezett patikán kívül nem sok minden
tanúskodik arról, hogy kötődik a városhoz.

A város mellett a folyóban rengeteg halat látni. A folyó melletti kövek között
pedig patkányokat, akik a nappali világossággal mit sem törődve hol a sziklákon
ugrálnak, hol pedig a vízben kergetik egymást.

Az már csak újabb ajándék, hogy a szűk utcákat járva melegen süt a nap, mintha
nem is október lenne. Rengeteget fényképeztünk, de még így sem tudjuk
visszaadni a város hangulatát.
 

Szólj hozzá!

Címkék: demoscene parti riport

Main party riport 2. rész

2010.10.01. 23:53 Travis.CG

A Marseille-be menő út korántsem volt zökkenőmentes. A mellettem lévő utas
arról kezdett panaszkodni, hogy rosszul érzi magát. Nemsokára a testét görcsös
remegés kezdte rázni. Az utaskísérőknek jelzett, azok mégis csak kb. 2 perc
múlva vették csak észre. Akkor viszont megkérdezték a nevét. Azt vettem
észre, azonnal a kiképzésen súlykolt dolgokat vetették be, meg sem
próbálták felmérni a helyzetet. Például az én kezembe nyomtak egy pohár vizet
és szinte felszólítottak, hogy igyam meg. A beteg melletti másik utasnak is
inni kellett. Egyáltalán nem voltam ideges. Latolgattam is, hogy nem iszom,
de végül úgy döntöttem, nem idegesítem a személyzetet, akik azért elég
nyugtalanok voltak. A beteg kapott a nyelve alá valami gyógyszert, majd
kólát itattak vele. Ettől gyorsan javult az állapota.

Arra is felszólítottak, hogy ne hagyjuk el a helyünket. Szerintem fertőző
betegségtől tartottak. Talán nem is alaptalanul, mert a hírek szerint
valami fertőzött szúnyog megszúrt egy embert Marseille-ben, így gondolom a
szokottnál is éberebbek voltak.

Később bemondták, hogy senki nem hagyhatja el a helyét, amíg az orvosok fel
nem szálltak és el nem látták a gyengélkedő utast. Már a leszállásnál láttam,
hogy a mentő várt ránk. Az orvosok feljöttek, és béna angolossággal
megkérdezték a beteget, hogy hogyan érzi magát. Megállapították, hogy csak
enyhe vérnyomás ingadozás volt. Adtak neki valami gyógyszert, majd távoztak.
Utánuk mi is.

A reptéren már vártak minket, és a parti helyszínére szállítottak. Elég kevés
embert láttunk. Fáradt voltam, de a produkciókat feltöltöttem a parti
szerverre. Első a kötelesség, utána a szükségletek. Miután minden fent
volt, elmentem aludni. Összecsukható tábori ágyakat kaptunk. Beállítottam a
fal mellé, kibontottam a hálózsákomat, bedugtam a füldugót és már aludtam is.

Szólj hozzá!

Címkék: demoscene parti riport

Main party riport 1. rész

2010.10.01. 18:45 Travis.CG

Frankfurt, nemzetközi repülőtér. Akár egy kémtörténet kezdősorai is lehetnének.
Unreal-al ülünk itt (bár ő már fekszik), és várjuk a csatlakozást, ami Marseille-ba
repít minket. Hozzávetőleg 5 órát kell várnunk, de szerencsére a járat, amivel
érkeztünk, késett, így a kényszerű várakozás lerövidült.

Unreal-nak nem ez az első késése. Vonattal érkezett a repülőtérre, ami szintén
késett, szinte az utolsó pillanatban értünk a bejelentkező pulthoz. Az utazás
ezt leszámítva eseménytelen volt. Utitársamnak ez volt az első repülése, mégsem
tetszett neki. Reméltem átragad rá az én lelkesedésem, de mikor azt ecseteltem
neki, milyen remek érzés, amikor a felszállásnál a székbe préselődik az ember,
inkább megrökönyödést láttam az arcán, mint örömöt. Elmesélte, hogy még a
hintát sem szerette gyerekkorában.

Frankfurt azt hiszem a legunalmasabb része az utazásnak. Megpróbáltam valami
munka szerűséggel foglalkozni, de nagyon hamar meguntam, és inkább egy effekt
írásába fogtam. Unreal aludni próbál egy kínai csoport mellett, akik a közelünkbe
vertek tanyát. A programozást is hamar meguntam. Nem csak azért, mert a CPU
nyüstölése gyorsabban emészti az akkumulátor kapacitását, hanem azért is,
mert nem jutottam közelebb a megoldáshoz.

Fáradok. A laptop telepe és az agyam versenyt merülnek. Minden egyes mondat
leírását két ásítás követ. Még két óra a gép indulásáig.
 

Szólj hozzá!

Címkék: demoscene parti riport

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