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

Slurm telepítés

2020.10.11. 22:49 Travis.CG

Egy feladatütemező előnyeit szerintem nem kell ecsetelni. Ennek ellenére léteznek olyan közösségek, ahol még mindig úgy indítják a szkripteket, hogy előtte toppal, ps-el és egyéb parancsokkal feltérképezik az elérhető erőforrásokat, majd vérmérséklettől függően lefoglalják a nekik szükséges részét.

Miért nem jó ez? Először is, a fenti parancsok nem látnak a jövőbe. Azért, mert egy adott pillanatban valamelyik felhasználó csak egy processzort használ, nem jelenti azt, hogy a szkriptje a következő lépésben nem fog 48-t felzabálni. A másik probléma, hogy aki először indítja a programját, az több erőforrást sajátíthat ki, mint aki a csak most ér vissza a nyaralásból.

A harmadik probléma, hogy ha én tudom, hogy sok erőforrásra lesz szükségem, akkor rendszeresen ellenőriznem kell, mikor szabadul fel az számomra. Ha például ez a hétvége kellős közepén történik, amikor épp egy bárgyú családtag unalmas történetét hallgatjuk végig századszor, akkor egy magányos munkatársunk, aki munkába folytja depresszióját, simán beelőzhet.

Egy feladat ütemező megoldást jelenthet ezekre a problémákra. Nekünk csak annyi a dolgunk, hogy elküldjük a szkriptet a megfelelő erőforrás listával, a többit a feladatütemező megcsinálja helyettünk. Az egyik legelterjedtebb feladatütemező a Slurm. Őszintén szólva, nem tudom, miben jobb ez, mint az LSF, Open Grid Scheduler vagy a többi, ami létezik. Felhasználói szinten minimális a különbség, rendszergazgai szempontból pedig csak a legelsőt ismerem.

Habár a Slurm sok csomagkezelőben előfordul, most mégis a forráskódból való telepítést fogom bemutatni. Ehhez egyetlen függőségre, a Munge-re lesz szükségünk. A dokumentáció szerint a fordítást a configure szkripttel kell kezdeni, de ne higgyünk neki. Azt először elő kell állítani. A teljes fordítás így fok kinézni:

./bootstrap.sh
./configure
make
sudo make install

Elméletileg érdemes létrehozni egy külön munge felhasználót, aminek a nevében fut a program, de a helyzet az, hogy a Slurm utána nem fog boldogulni vele, ha így teszünk. Inkább hagyjuk ki. Nem tűntettem fel, de van egy lépés, amelyik teszteli, mennyire sikeres a fordítás, de nem érdemes lefuttatni. Egy csomó hibát fog generálni, mert a létrehozott teszt könyvtárak jogosultságát problémásnak tartja. A program ugyanis nem szereti, ha a group-nak bármilyen jogosultsága van a munge által kezelt könyvtárak felett. Elméletileg, ha a /tmp-be tesszük át a teszt könyvtárakat (make check root=/tmp paranccsal), akkor nincs ilyen probléma, de nekem nem működött. Ugyan úgy dobálta a hibákat. A végleges könyvtárak viszont megfelelő jogosultsággal fognak létrejönni, ezért ezeket a hibaüzeneteket nem kell komolyan venni.

Ezt egyébként érdemes észben tartani hibakeresés közben. Ha nem megy a program, 90%, hogy jogosultság gond van. Mielőtt elindítanánk a munde démont, hozzuk létre az azonosításhoz szükséges kulcsot.

sudo mungekey

Most már készen állunk a Slurm telepítésre. Ezt is letöltjük, kibontjuk, majd jöhet a ./configure; make; sudo make install hármas. Sok esetben viszont érdemes időt szánni a konfigurálásra. Például ha nincs szükségünk grafikus felületre (márpedig egy távoli szerveren legtöbbször nincs), akkor a nyugodtan használjuk a --disable-x11 opciót.

Telepítés után jöhet a rendszer beállítása. Először létre kell hozni egy slurm felhasználót. Kell készíteni egy konfigurációs fájlt itt. Igen, egy weboldalon. Nekem a memória beállításával volt problémám, mert azt gondoltam megadhatok mértékegységeket. Nos, nem. Ha az aktuális node paramétereire vagyunk kíváncsiak, a slurmd -C paranccsal kiírathatjuk azt. Ez segíthet meghatározni, mekkora erőforrásokkal rendelkezik az adott node.

Miután kitöltöttük a webes konfiguráció szerkesztőt, letöltjük a kész fájlt a beállításokkal, és bemásoljuk a megfelelő helyre slurm.conf néven. Ha nem állítottuk be a --prefix opciót konfigurálásnál, akkor ez a könyvtár az /usr/local/etc lesz. Tegyünk mellé még egy konfigurációs fájlt, aminek a neve cgroup.conf. Ezt elfelejti említeni a dokumentáció, de higgyétek el, hogy kell. Hiányában a Slurm képtelen lesz a jogosultság kezelésre. Tartalma a következő:

CgroupMountpoint=/sys/fs/cgroup
CgroupAutomount=yes

Felvehetünk más opciókat is, amivel a job-ok által felhasznált erőforrásokat tudjuk limitálni. Ez akkor lehet hasznos, ha a gépen más program is fut, aminek szeretnénk állandó erőforrásokat biztosítani.

Ezután létre kell hoznunk különböző könyvtárakat, amelyeket a Slurm arra használ, hogy nyilván tartsa a futó folyamatokat.

sudo touch /var/run/slurmctlf.pid
sudo touch /var/run/slurmd.pid
sudo mkdir /var/spool/slurmd
sudo mkdir /var/spool/slurm.state

Mindegyik legyen a slurm felhasználó birtokában! Némelyik fájl neve ismerős lehet a slurm.conf fájlból, ezért ha ott átírtuk, akkor más névet kell megadnunk a fenti parancsoknál is.

Most már elindíthatjuk a démonokat. Először a slurmctld-t kell, majd a slurmd-t. Ezzel készen is vagyunk. Amennyiben több nodot használunk, úgy a munde és a slurmd-t az összes nodon el kell indítani.

A fenti lépésekkel egy nagyon egyszerű ütemezőnk lesz. A konfigurálást a végtelenségig lehet bonyolítani. Lehet különböző queue-kat létrehozni más-más limitekkel, korlátozhatjuk a felhasználókat, hogy mennyi ideig használják a rendszert (például jó ötlet lehet egy maximális futási időt megadni, mert mohó bioinformatikusok kisajátíthatják a teljes infrastruktúrát).

Hasznos link:

Leo's Notes

Szólj hozzá!

Címkék: rendszergazda

Tíz év, 500 bejegyzés

2020.09.30. 20:00 Travis.CG

Nemrég kíváncsi lettem, mióta is írok blogot. Mint kiderült, pontosan tíz éve. Egy másik kerek évforduló is van, ugyanis ez az 500. bejegyzés (van három bejegyzés, amit visszavontam, az 500-ba azokat is beleszámoltam). Bevallom, azért egy kicsit manipuláltam a dolgokat, hogy pont mára jöjjön ki, de nem számít. Szeretjük a tízzel és százzal osztható számokat, még akkor is, ha matematikailag semmi különös nincs bennük.

A blognak jelenleg négy aktív követője van. A legnépszerűbb bejegyzés már bioinformatikai, és nem a villanybojler kontárkodásom, ami sokáig vezette a toplistát. Aminek külön örülök, hogy az olvasóim fele (59%) 800x600-as felbontásban nézi a blogot. Érdekes módon az ismeretlen böngészők száma is hasonló (51%), akik nem a Firefox-Chrome-Safari triumvirátusba esnek, és az ismeretlen operációs rendszert használók aránya (46%) sem tér el nagyon.

Természetesen lehet, hogy ez a három tény egymástól független, de nehezen tudom elképzelni, hogy valaki direkt 800x600-on kínozza magát Windows 10 alatt. Sokkal valószínűbb, hogy valami alternatív platformon olvassák. Nem gondolom, hogy ez MorphOS lenne, mert azt többnyire PowerMac-en használják, ami nagyobb felbontással üzemel. A 800x600 egyértelműen valami régi rendszer lesz, ami a 2000-es évekre hajaz.

Átlagosan napi 12 lapletöltés van, aminek a nagy része a Google és a Bing. Senki nem szokta linkelni az oldalakat, nem is igen hivatkoznak rá. Egyszer a prog.hu feltűnt hivatkozónak, de soha nem akadtam rá, melyik bejegyzés keltette fel az érdeklődésüket.

Ez a nagy ismeretlenség nem meglepő. A magam részéről soha nem reklámoztam a blogot. Nem árultam el senkinek, hogy blogot írok (na jó, egy embernek mondtam, de szerintem ő másnap el is felejtette). Amint mindenki láthatja, ki vannak kapcsolva a reklámok is, amivel azonnal levettek a főoldalról is. Ez egy tudatos döntés volt, mert kíváncsi voltam, mennyire akadnak rá az emberek marketing nélkül. Annak ellenére, hogy nem emelkedtem influenszeri magaslatokban, bioinformatikai körökben elég elterjedt a blog. Legalábbis erre enged következtetni, hogy sok olyan emberrel találkoztam konferenciákon, akik a blog alapján ismerték a munkámat.

A másik ok (amellett, hogy kicsit csapongó, sok helyen nehezen követhető az irásom), hogy a téma nem sok embert érdekel. Egy filmkritika sokkal több embert tud bevonni, mint a szerencsétlenkedés a számítógépekkel. Ha viszont csak a célközönséget nézem, akkor azt gondolom, elég nagy százalékukhoz eljutottak az üzeneteim. Ezt sikerként is felfoghatom.

4 komment

A bioinformatika szépségei (és szörnyetegei)

2020.09.29. 21:58 Travis.CG

Néha a bioinformatikai munka olyan, mintha egy kísértet járta házat fedeznénk fel. Nappal. Tudjuk, hogy vannak szellemek, de azt hisszük, ezek csak éjszaka jönnek elő. A rontások tényleg nem szeretik a fényt, de nappal is vannak árnyékos helyek...

Nemrég gomba szekvenciákat kellett összeraknom. Pontosan nem tudtuk, milyen gombákból származtak ezek, ezért az ITS régió azonosítása nagyon fontos volt. Kétféle szekvencia állt rendelkezésünkre. Az egyik a szokásos Illumina volt, a másik Nanopore. Az Illumina mintavételénél a laborosok biztosak voltak benne, hogy Staphylococcus fertőzés is történt, ezért azokat különösen óvatosan kellett kezelni. A Nanopore-al ilyen probléma nem volt.

Több összeszerelést is végrehajtottam. Csak Illumina readek alapján, csak Nanopore szekvenciákkal és persze hibrid összeszerelést is végeztem. Nem akartam a fertőzéssel sokat bajlódni, ezért először csak a Nanopore szekvenciákkal épített genomot vizsgáltam. Az ITS régiók kópia száma 37 volt. Úgy gondoltam, ez nagyon sok, mert a referencia Saccharomyces genomokban 2 szokott lenni. Igazából volt más probléma is ezzel a genom összerakással (például a teljes mitokondriumnak csak 1/8-ad részét sikerül összerakni, az indelek száma meglepően magas volt), ezért tovább kellett lépni.

Megnéztem a hibrid összeszerelést is. Ez már ígéretesnek tűnt. Megvolt a teljes mitokondrium, viszont egészen biztos, hogy vannak benne olyan szekvenciák, amelyek nem gombából származnak, hála a fertőzésnek. Az összeszerelt scaffoldokat szűrni kellett valahogy. Először csak a baktérium genomokra illesztettem, majd ami arra felment, eltávolítottam. Ezután kerestem csak az ITS régiókat. Egy felet találtam! Ez elég szokatlan szám volt a 37 kópia után, amit a másik módszerrel határoztam meg. Megnéztem a szűrés előtti szekvenciákat, és két darab jött fel, akár csak a nagy könyvben.

Tehát túl szigorúan szűrtem. Nézzünk egy jobb szűrési módszert! Illesztettem a baktériumokra és a Saccharomycesre is. A két illesztésre adott pontszámot (bennfenteseknek: a Blast bitscore-t) pedig ábrázoltam egy koordináta rendszerben. A vízszintes tengely a baktérium illesztések pontszáma, a függőleges a gomba illesztés pontszáma. A szekvenciák egy része szépen szegregálódik. Ami a vízszintes tengelyhez van közel, az baci, ami a függőleges tengelyhez van közel, az gomba. Egyértelmű.

bitscore.png

De mi a fene az a sok szekvencia az átló mentén? És miért vannak pontok az átlón? Hogyan lehetséges, hogy egy szekvencia közel olyan jól illeszkedjen a gombához is, mint a baktériumhoz? A horizontális géntranszfert sok mindenre rá lehet húzni, de erre nem.

Elkezdtem megnézni, miféle baci lehet ez. Az adatlapja szerint egy szekvenálásból származó szekvencia darabka. Egy hasonló kísérletből származik, mint amilyen az enyém is. Nekem is darabkáim vannak, nekik is darabkáik voltak. Én gombát akartam összerakni, ők baktériumot. Rá is engedtek mindenféle programot, ami talált géneket, érdekes régiókat, stb. Az NCBI pedig beemelte a referencia szekvenciák közé, és a reprezentatív baktérium Blast adatbázis része lett.

Ha viszont megnézzük, mivel mutat homológiát (bárki megteheti, van egy Run BLAST gomb jobb oldalon), akkor egy gombát találunk! Húúú, a szellem kibújt! Mégis csak elég hasonló a kísérlet az enyémhez! Amig nekem baci fertőzésem volt, addig nekik gomba jutott. De még én mindent elkövettem, hogy az idegen szekvenciákat eltávolítsam, addig ők ezzel nem sokat törődtek. Szinte belegondolni is rossz, hány ember használ ehhez hasonló adatokat, abban a hiszemben, hogy amit a szekvenciák leírásban találnak, az hiteles információ.

Természetesen az egyes adatbázisokban előforduló hibák nem újkeletű dolgok. Emlékszem, annak idején a MisPredre, ami az EnsEMBL hibásan detektált fehérjéit igyekezett kijavítani. Még én is "dinoszaurusz" DNS Blasztolását adtam fel egy állásinterjún feladatnak. De még a humán szekvenciák is okozhatnak szennnyezést a baktérium szekvenciákban.

Tehát mindenki legyen éber, mert bármikor beterítheti egy kis nyálka egy forduló után.

Szólj hozzá!

Címkék: bioinformatika

Cseppet sem objektíven: Function 2020

2020.09.28. 14:42 Travis.CG

Úgy döntöttem, kihagyom az idei Function-t. Sokat gondolkodtam a döntésen, ettől a motivációm is lecsökkent, ami öngerjesztő folyamatként afelé mozdított, hogy release nélkül nem kéne partira mennem. Végül addig halogattam a döntést, hogy kifutottam az időből.

Egy partinak mindig van egy kis szürreális hatása. Úgy értem, egy kívülálló számára érthetetlen, miért ujjonganak emberek a kivetítőn látható absztrakt formák láttan, és még egy informatikus számára is felfoghatatlan, milyen nyelven beszélnek. A régi és modern számítógépek által generált világok egyszerre vannak jelen, amitől minden időtlenné válik. Mégis, mikor elkezdtem nézni a közvetítést, még nekem is sokkoló volt a látvány.

Egy gázállarcos fickó ugrált egy laptop előtt, miközben maszkos alakok táncoltak előtte. Oké, újabb adalék a furcsaságok gyűjteményéhez. Bár ezek után el sem tudom képzelni, milyen lehet egy valódi posztapokaliptikus demóparti.

A releasekre viszont nem lehetett panasz. Az oldschool kategória kimagasló eseménye a Genesi Projekttől a Memento Mori. Nagyon egységes témája volt, még a lemezoldalak váltására szólító üzenetek között is olyan idézeteket szerepeltek, amelyek képesek voltak a hangulatot fenntartani. Rengeteg artwork volt, szép scrollok és gyönyörű zene. Az effektek is látványosak voltak.

A Lethargy is egy remekül megkomponált demóval érkezett. Témája a Nintendós játékok. Mivel manapság már a csapból is Mario folyik (nem tudunk egy nyomorult Kinder tojást sem venni anélkül, hogy ne egy teki katona essen ki belőle.), annyira nem ragadott magával a nosztalgia vonat, de az effektekre itt sem lehetett panasz.

Ha már Nintendo, akkor legyen SNES kövér. Egy 3D flyby-t kaptunk, a monoton fajtából. Aki nem követi a demoscene apró rezdüléseit, annak megemlítem, hogy vannak az oldschool kategóriákban bizonyos témák, amelyekhez bátran nyúlhat az, akinek semmi ötlete inkább a technikai kihívásokkal kíván foglalkozni. Az egyik ilyen a Bad Apple, a másik a STINCCC. Most ez utóbbit láthattuk.

A 256byte intrók mindegyike szokás szerint magas színvonalat képviselt. Hirtelen nem is tudnám megmondani, melyik tetszett a legjobban, de a Bit Runner 2048 jelez egy új trendet. Mostantól a multipart intrók a nyerők ebben a kategóriában. Nekem nagyon tetszett a Hydraulic Pixels is, mert első ránézésre nem lehetett megmondani róla, hogy ez egy 256 byte intró. Mivel a legtöbb intró 640x480 256 színes videómódot használ, ezért egy idő után rögtön felismeri az ember, hogy mivel van dolga. Ennél az intrónál ez nem következett be.

A többi intró kategória nem volt valami nagy szám, bár Archee kerek popós rolleres alkotása nagyon vicces volt, főleg, ahogy a végén twerkeltek, vagy mit csináltak.

Az idei demóknál nem is a technikai részleteken volt a hangsúly, hanem az elvontságon. A Rainbow Clash végre szakított azokkal kaptafára gyártott demókkal és végre csináltak valami mást. Nem állítom, hogy pontosan értem, mit is kaptunk, de akkor is üdítő, hogy nem egy kellemes zenére rádobált random színes objektumok halmazást kellett nézni. A Rebels is belépett a game engine korszakba, és remekül helyt is álltak Unitys demójukkal. Gargaj egyszemélyes hadserege ismét támadást intézett a "szokványos demók" bástyái ellen. Azt hiszem, meg sem próbálom szavakba önteni, mit éreztem a demó megtekintése közben. Ezzel nem azt akarom mondani, hogy rossz, amit láttunk, inkább azt, hogy az értelmezéseim eddig sem fedték le a valóságot.

Végezetül volt egy nem release jellegű esemény, ahol a Function egykori és mai szervezői rengeteg belső információt osztottak meg egy beszélgetés keretében a hallgatósággal. Nekem, aki mit sem tudott erről a szubkultúráról 2007 előtt, remek anyag volt. Szerintem még külsősöknek is érdekes lehet.

Összességében nekem pozitív volt a tapasztalatom a partival kapcsolatban, és maximálisan tisztelem a szervezőket, hogy még ilyen időkben is kitartanak, nem adják fel. Hiszen megtehették volna, hogy bedobják a törölközőt.

Szólj hozzá!

Címkék: demoscene

Vesztettem

2020.09.16. 22:09 Travis.CG

Akkor leszünk középkorúak, amikor a fiatalos lendület megtörik, és feladjuk azokat az elveket, amelyekért éveken keresztül küzdöttünk. Előbb-utóbb mindenki elér erre az állapotra, nem véletlen, hogy az egyes tüntetéseken fiatalok vannak, és a különböző aktivista fórumok sem vén csontokból verbuválódnak.

Nekem egyetlen, icike-picike harcom volt az Excel nevű többfejű szörnyeteggel. Következetesen elutasítottam mindent, amit ez a program képviselt, és erre másokat is próbáltam rávenni, nem túl etikus eszközökkel: "Ja, Excelben kérted? Teljesen elfelejtettem. Nem baj, így is meg tudod nyitni." vagy "Nem nyitja meg az Excel? El sem tudom képzelni, mi lehet a baj," esetleg "Bocs, Linuxom van."

Máskor perverz élvezettel hívtam fel a program hiányosságaira a figyelmet, majd széttártam a karom: "nekem nincs ilyen problémám, én nem használom."

De most mindennek vége. Legyőztek.

Az első támadás egy kooperáló partner képében jött, akik jó ideje nem küldtek nekünk elemezni való adatot, helyette egy másik csoportot kértek fe, hogy végezzék el a munkát. Mivel az a csoport nem olyan jó, mint mi (hehehe), ezért a mi segítségünket kérték. Nem magához az elemzéshez, hanem az infrastruktúra felállításához. Tehát kerülőúton ugyan, de valamilyen szinten mégis hozzánk jutott a munka.

Mikor azt próbáltuk kipuhatolni, ugyan miért nem volt jó, amit mi csináltunk, az volt a válasz, hogy nem Excelben küldtük az eredményt. Ha ez igaz, a makacsságom hatására buktunk egy melót. Ez azért fájt.

A második sokk ebben a cikkben ért. A HGNC átnevezi azokat a géneket, amelyek nevét az Excel dátummá alakítja. Ez döbbenet. Nehogy már béne Windows felhasználók igényei szabják meg, mik legyen a gének nevei! Márpedig pontosan ez a helyzet. Mi lesz a következő? A FASTA fájlokat lecseréljük Word dokumentumokra? Jegyzőkönyvet pedig PowerPointban kérik ezután?

Úgyhogy ideje elismernem, hogy vesztettem. Ilyen erők ellen nem lehet harcolni.

Szólj hozzá!

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

Malacságok

2020.09.16. 10:32 Travis.CG

Bevallom, már nem is emlékeztem, mit csináltam ebben a cikkben. Teljesen kiesett. A projekt még 2016-ban kezdődött, amikor végeztünk a mangalica cikkel, és jelentős adatunk volt különböző sertés szekvenciákból. Belekezdtünk különféle markerek keresésébe, amelyek némelyike politikai döntés miatt halálozott el, mások nem bírtak elég jelentős gazdasági haszonnal.

Ezekbe a döntésekbe nem láttam bele, nekem csak az volt a dolgom, hogy temérdek BAM fájlból "érdekes" régiókat halásszak ki, tonnányi IGV képet generáljak, amit aztán a Windowson szocializálódott kutatók bogarászhattak. Arról sem szabad megfeledkezni, hogy abban az időben nekem volt a legerősebb gépem az intézetben, játszi könnyedséggel hajtottam végre ilyen feladatokat, miközben más munkákra tudtam koncentrálni.

Azután nem jött több kérés, én nem erőltettem a dolgot. Csatlakoztam a Sanger csapatához, ezért annak rendje és módja szerint elfelejtettem az egészet.

Egy nap viszont levelet kaptam, hogy szerző vagyok egy publikációban. Gyorsan megkérdeztem, miféle munka volt ez? Elmondták, hogy a rengeteg marker keresésből a vaddisznó marker azonosítása sikeres lett, de közben az is kiderült, mások is majdnem elfelejtették, mivel járultam hozzá a cikkhez, de a levelező szerző szerencsére nem volt olyan feledékeny, mint én.

Igazából azért érdekes ez a cikk, mert azon kevesek egyike, amikor a munkámnak közvetlen, kézzel fogható haszna van. Ezzel a publikációval lehet menőzni azoknál az embereknél, akik csak üres tekintettel bólogatnak, ha valami alapkutatásból származó eredményemről beszélek.

Szólj hozzá!

Címkék: publikáció

Négy százalék tudomány

2020.09.07. 22:05 Travis.CG

Nagyon érdekel a sötét anyag kutatás, és nem csak azért, mert vagyány neve van. Van egy olyan rossz tulajdonságom, hogy amihez nem értek, azt túlmisztifikálom. Az ismeretterjesztő könyvek viszont segítenek helyre tenni a dolgokat. Ezért is olvastam el Richard Panek, 4% univerzum című könyvét.

A könyv a kozmológia hőskorának bemutatásával kezd, amikor felfedezték a kozmikus háttérsugárzást, később az univerzum tágulását. A könyvben a tudományos rész viszonylag kevés, sokkal többet mutat be az egymással versengő kutatókról, és azok személyiségéről. Ezt az első fejezetekben még átszövi egyfajta pátosz, de ahogy halad előre a könyv, és közelítünk a jelenhez, egyre inkább olyan lesz, mint egy OTKA bírálat kulissza titkai: Tudod, hogy korrupt a rendszer, de még így is arcon csapnak a tények. Csak itt azzal szivatják egymást a kutatók, hogy nem engedik a Hubble űrtávcsövet használni a konkurenciának.

Mindezt talán valami hatalmas tudományos célért teszik? Nem, csupán azért, hogy néhány tizedesjeggyel pontosabban kiszámolják azt a kozmológiai állandót, amit az elméleti fizikusok próbáltak elfelejteni. Ezen a ponton, határozottan gyűlöltem már a könyvet. Mert míg más tudomány területen kifogásolják, ha a kitűzött célok nem elég előre mutatóak, a könyv azt sugallta, hogy az Egyesült Államok csillagászai egyre nagyobb berendezéseket építenek, egyre több pénzt vernek el, miközben igazolják azt, amit egy galamb ürülékkel teleszórt tányérantennával is látni lehet. (A Bell mérnökei ugyanis attól féltek, hogy a galambpiszok okozza azt a zajt, amit később kozmikus háttérsugárzásnak azonosítottak.)

Azért biztos vagyok benne, hogy mást is publikálnak egyetlen számértéknél, hiszen a PhD hallgatókank is kell az első szerzős cikk, de nem éreztem a nagy áttöréseket. Einstein beleírta a kozmológiai állandót az egyenleteibe. Aztán kivette. Mások meg visszatették. Mintha az egész tudományág körbe-körbe menne.

A másik dolog, amin nagyon kiakadtam, hogy ugyan olyan módszertani hibákat követettek el, mint amiket én is megemlítek néha a blogomban. Az egész azért is dühítő, mert két, egymástól független csoport is elkövette őket!

Lecsupaszítva az történt, hogy két konkurens csoport figyelte a szupernovaként felrobbanó csillagokat. Ez azért volt fontos, mert ezek fényerejének változásából nagy pontossággal meg lehet határozni a távolságukat. Gyakorlatilag galaxisok Földtől mért távolságát és sebességét mérték. Ezeket egy grafikonban ábrázolták.

Az SCP csoportot részecske fizikusok alkották, akik az elején semmit nem tudtak a csillagászatról, viszont kitaláltak egy módszert, amivel annyi szupernovát tudtak detektálni, amennyit csak akartak. A másik csoport, amire a könyvben Nagy-z csoportként hivatkoznak, csillagászokból állt. Ők pontosabban megfogalmazott tudományos kérdésekre keresték a választ, viszont nagyon nehezen találtak szupernovákat.

Az SCP csoport a vizsgálatok korai szakaszában, mikor kevés szupernovájuk volt, írtak egy cikket, és felállítottak egy magyarázatot. Ahogy telt-múlt az idő, néhány olyan szupernovát találtak, amelyek nem illettek bele ebbe a magyarázatba. Mit csináltak ezekkel az adatopontokkal? Nem közölték, hanem kihagyták őket! Az volt az indok, hogy a szavahihetőségüket aláássa, ha mindig más eredményt közölnek.

Ahogy telt-múlt az idő, annyi ilyen "kiugró érték" keletkezett, hogy már nem hagyhatták őket figyelmen kívül. Akkor meg azon mesterkedtek, hogy minél előbb leközöljék és rettegtek, hogy a konkurencia beelőzi őket. Ugyanis a Nagy-z csoport kezdett feljönni a szupernovák számában, ráadásul már a kezdetektől pontosabb méréseket hajtottak végre, mert tisztába voltak egyéb csillagászati problémákkal is. Ahogy közeledett a Nobel-díj kihírdetése, úgy kezdett egyre szemetebb módon viselkedni egymással a két csoport. Civakodtak, mint az óvodások. Könyveket írtak, ahol mindenki saját magának tulajdonította a felfedezést, holott egyedül egyikük sem lett volna képes még a megfigyeléseket sem elvégezni.

Az egészhez az egyetemek még PR csapatokat is mozgósítottak, akik olyan komoly tudományos tevékenységet folytattak, hogy Washington Post és New York Times kaliberű újságokban közöltek híreket. Mélységesen megdöbbentett az egész.

Ahogy a látható anyag is csupán töredéke az univerzumunknak, úgy a tudomány is csak nyomokban fedezhető fel a sötét anyag kutatásban. A többi politika, cselszövés, árulás.

Szólj hozzá!

Címkék: filozofálás

Processzor reanimáció

2020.08.31. 22:22 Travis.CG

Az számítógépem szép lassan megdöglött. Nehezen indult, könnyen fagyott. Fagyás után megint nehezen indult. Egy ideig bírtam is a hóbortjait, de a munkát egyre nehezebben lehetett ellátni vele.

Először csak a játékok terhelték meg. Egy óra játék után annyira felforrósodott, hogy a burkolat szinte égetett. Levettem az oldalát, és elfektettem, hogy videókártyától érkező meleg levegő ne a processzort fűtse, de ez sem segített sokáig. Azután a helyzet tovább romlott, egyre rövidebb ideig tudott futni egyhuzamban. Végül 10 percet sem tudtam használni anélkül, hogy le ne fagyott volna. Eljött az idő, hogy megjavítsam.

Először a tápegységre gyanakodtam, de a multiméter és a diagnosztikai programok szerint is stabilan adta le a 12 és 5 voltot is. A memóriára gyanakodtam másodjára, de Windows alatt az Aida64 memória tesztelő modulja semmit hibát nem talált. (Volt egy kis kalandom a CentOS vészmódjával is, de nem akarom annyira részletezni, mennyi mindent sikerült elrontanom. Elég az hozzá, hogy elindítottam emergency módban, és utána csak abban tudtam elindítani.)

Processzor tesztnél viszont 3 perc után fagyott, a következő újraindításnál, ha nem tudott bootolni, az alaplapon a CPU indikátor ledje folyamatosan világított. A dokumentációja csak annyit írt, hogy szüntessük meg a CPU problémát, és akkor menni fog. Oké, de milyen problémája lehet egy CPU-nak? Pontosabban mi olyan problémája lehet, amitől néha megy, néha nem?

A neten találtam egy leírást, mely szerint érintkezési hiba léphetett fel, vagy a nem megfelelő hűtés okozhat galibát. A hűtő ventillátor megfelelően működött, nem értettem, mi baj lehet vele. Az érintkezési hiba pedig olyan misztikus. Nem tudtam elképzelni, hogy lezárt processzor foglalatban miként léphet fel érintkezési hiba, de ez volt az egyetlen nyom, amin elindulhattam. Úgy döntöttem, kiszedem a processzort.

Megpróbáltam leszedni a hűtőt a CPU-ról, de az úgy rá volt ragadva, hogy nem mozdult. Életemben nem láttam még ilyet! A régi, leselejtezett alaplapjaim hővezető pasztái még 20 év távlatából is összemaszatolták a kezem, mitől köthetett be ez a viszonylag fiatal? (Fiatal? Hét évvel ezelőtt raktam össze, azóta csak a grafikus kártyát cseréltem.) Lehet, hogy ez okozta a gondot? Megszáradt és nem volt képes a CPU leadni a hőt?

De akkor is ki kellett szedni valahogy, ha újra akarom pasztázni. Gondoltam, egy kis csavarás talán segít...

Segített is. Kijött a processzor is, hűtő is a lezárt foglalatból! A paszta továbbra is betonként tartotta egybe a két részegységet. A processzor apró réz kivezetései közül néhány elgörbült. Ezt jól elintéztem.

Egy fórum bejegyzés szerint melegítés hatására elválnak. Én próbáltam melegíteni, nem hajszárítóval, ahogy javasolták, hanem egy öngyújtóval a hűtőbordák alját melegítve, de nem használt. Az okos megoldás ha nem működik, majd a nyers erő fog. Fogtam az egyik mindenes bicskámat, és szép lassan elkezdtem szétfeszegetni a hűtőt és a processzort. A művelet során nem sikerült jól megfognom a CPU-t, ezért további lábak deformálódtak el. Végül elváltak egymástól. Egy probléma megoldva, de keletkezett egy újabb.

A bicskával lekapartam a kő kemény pasztát, majd alkohollal letiszítottam a vékony szennyeződéseket (Az ujjlenyomatokról nem is beszélve, mert antisztatikus kesztyűt csak a gyengék használnak). A hűtő alján a rézlemez kicsit karcos lett. Gondolkodtam rajta, hogy esetleg kicsit polírozok rajta, de végül letettem róla. Gondoltam, majd a paszta megoldja. Inkább fogtam egy csipeszt és egy nagyítót és szépen lassan elkezdtem visszaegyenesíteni a processzor lábait.

Ez elég sokáig eltartott. Beletettem a foglalatba, próbáltam a kezemmel érzékelni, hol nem megy a helyére, majd kivettem és állítottam még egy kicsit rajtuk. Szerencsére egy teljes sor nem görbült el, így a szomszédos lábakat referenciának tudtam használni. Végül a helyére került. Jöhet a paszta.

Volt egy doboz pasztám, amit nagyon régen vehettem, mert a rajta lévő árcédula tanúsága szerint 600 forintot fizettem érte. Szerintem 2000. után történhetett, de nem vagyok benne teljesen biztos. Meddig lehet jó egy ilyen paszta? Az állaga jónak tűnt, meg ennél több kárt már nem tudok okozni ennek a gépnek, ezért bekentem vele. Visszaszereltem a hűtőt, és áram alá helyeztem.

Nem szikrázott, amit jó jelnek vettem. Elindítottam. Az első meglepetés az volt, hogy a hűtő sokkal csendesebb lett. Ismét ráeresztettem az Aida64-t. Még teljes terhelés mellett sem volt olyan hangos, a hőmérséklet pedig nem ment 70 °C fölé. Fél óra tesztelés után megnyugodtam. A küldetés sikeres volt.

Szólj hozzá!

Címkék: rendszergazda barkácsolás

Többszörös illesztés

2020.08.25. 22:21 Travis.CG

A többszörös illesztés régen egyszerű volt. Fogtuk a szekvenciákat, bedobtuk a ClustalW-be és illesztettünk. Később jött a Mafft, Muscle és a társai, de a recept nem változott sokat.

A szekvenciák aztán hosszabbodtak és már mindenki genomokat akart illeszteni ezresével. Nem csak az aktuális járvány miatt, hanem egyébként is. A gépek viszont még nem állnak azon a szinten, hogy ezt a régi módszerekkel véghezvigyük, ezért megjelentek az egyszerűsítések és a különféle stratégiák.

Bizony, ami régen rutin feladat volt, manapság művészetté lépett elő, ahogy a DECIPHER dokumentációja is sugallja. Röviden nézzük is át, milyen stratégiák vannak!

Régi iskola

Ezt csináltuk régen, és ezt csináljuk most is, ha egyszerű hipotézisekkel dolgozunk. Veszünk egy gént, régiót, majd illesztünk. Általában olyan gént, ami minden, a kutatásban szereplő élőlényben megvan, mint például a jó öreg 18S alegység. A szekvenciák kollineárisak, közel azonos hosszúságúak, használhatjuk a régi jó dolgokat. Az összes bioinformatikai könyv, cikk, bejegyzés ezzel van tele. Előnye, hogy egyszerű, kicsi a hibázás esélye. Viszont nagyfokú szekvencia homológia esetén teljesen használhatatlan, mert minimális lesz a különbség a vizsgált szekvenciák között. Nem lesz olyan szerencsénk, hogy ezt a módszert kelljen használni.

A ráncfelvarrt

Ez majdnem ugyan az, mint az előző, csak sok homológ szakaszt vesznek, azokat mesterségesen összeragasztja, és egy nagy szekvenciával dolgoznak. Egyesek odaig is elmennek, hogy 1500 gént raknak egymás után. Közelrokon fajoknál növeli a szekvenciák diverzitását, de több gond is van vele. Először is, a gének evolúciós sebessége eltérhet. A végső hasonlóságot a hosszabb gének fogják megszabni, ráadásul a gének illesztésének helyén nagyobb eséllyel lesz gap, amit minden illesztőprogram rosszabbul súlyoz, és a később a fa építésénél a valós evolúciós távolságnál nagyobb távolságot kapunk. Ennek a módszernek semmi biológiai relevanciája nincs, szerintem azért csinálják, mert még mindig vissza tudnak nyúlni a megszokott programjaikhoz. Ezt a módszert lehetőleg soha ne használjuk, nyugodtan vállaljunk be egy összeveszést a főnökünkkel, ha erre akar kényszeríteni.

Vadnak született

A helyzet az, hogy legtöbb esetben nincs teljes genomunk, csak dirib-darab szekvenciáink. Ha van is genom, a kollinearitás nem garantált, nekünk mégis ezzel kell dolgoznunk. A megoldás, hogy több homológ szakaszt veszünk, akár csak az előző módszerben, csak nem ragasztjuk össze őket. Több többszörös illesztést végzünk és több fát készítünk, ha evolúciós kapcsolatokat is látni akarunk. De melyiket illesztést, és azon keresztül melyik fát fogadjuk el végső eredményként? Természetesen az összeset, egy konszenzus fa képében, amit például az Astral nevű program is elkészíthet. Kolinearitás garantált, fragmentált genom esetén is működik, közel rokon fajoknál is lesz elég távolság, mégsem viszünk mesterséges hibát a feldolgozásba. Természetesen ez a mószer a legmacerásabb, de szerencsére akadnak, akik nem riadnak meg tőle.

A kívülálló

Érdekes módon a progressiveMauve az általam ismert egyetlen program, ami elfogad bármilyen genomot, akár draft genomokat is, és tudásához mérten elvégzi az illesztést. Az előbb említettem, hogy több homológ szakaszt kell keresni, de baktériumoknál, ahol a horizontális géntranszfer tovább bonyolítja a helyzetet, néha azzal szembesülünk, hogy a homológ gének nem feltétlenül egy leszármazási egységre jellemzőek.

Ez a program viszont autómatikusan megkeresi a synteny blokkokat, meghatározza azok orientációját, létrehoz egy hierarhikus fát, amit vázként használ a precíz illesztéshez. Ez az úgynevezett "guided tree" meglepően korrekt fát hoz létre. A cikk és dokumentáció szerint nem használható filogenetikai elemzésre, de a kollégáim szerint az eredménye nagyon egybevág a biológiával, legalábbis az eddig vizsgált bakteriális genomok esetén így volt.

A módszer hátránya, hogy régi a  kód, nem használja ki a többmagú processzorokat. Másik hátránya, hogy bakteriális genomoknál hosszabb szekvenciák illesztése rengeteg időt vesz igénybe.

Szólj hozzá!

Címkék: bioinformatika

Szakmák, amikhez mindenki ért: járványtan

2020.08.16. 22:11 Travis.CG

A mai világban nem elég, ha jó szakember valaki, innovátornak kell lennie. A pszichológus is life coach, ha ki akar törni a szürke munkások hadából. Ha pedig rájön valaki, hogy a súlyokat máshogy is lehet emelgetni, akkor azonnal egy többlépcsős tanúsitvány rendszert segítségével biztosítja, hogy csak ő adhassa tovább a tudást. Mindhárom esetben el kell jutni arra a szintre, hogy sok embernek mi, és csakis mi mondjuk meg a tutit, mert csak akkor leszünk valakik. Ez pedig szükségszerűen versenyhelyzethez vezet.

Erre két módszer van, hogy ezt elérjük. Az egyik, hogy hosszú évek munkájával, folyamatos fejlesztéssel eljutunk erre a szintre, miközben szép lassan, ezzel párhuzamosan növekszik a reputációnk is. A másik módszer egyszerűbb: felvesszük a "megmondó ember" attitűdöt, és becserkésszük azokat, akik elhiszik ezt. Vagyis jó hangosan, minél szélesebb közösségnek kell nagyon magabiztosan eladjuk magunkat.

Bárkit megkérdeznénk, biztos vagyok benne, hogy az első csoportba sorolná magát. De ha elolvassuk a Twittert, Facebookot, valahogy mindig a második csoport kerül túlsúlyba. Én ugyanis ennyi hülyeséget még nem hallottam, mint amennyi a COVID-19 kapcsán előkerült.

Az 5G hálózatok, mint a vírus terjesztői, vagy az ellenanyagba rejtett mikrochip kezdetű teóriákon nem akadok fenn. Ezek szerintem teljesen természetes velejárói annak a sokknak, amit egy globális terjedésű vírus az emberiségből kivált. Bármilyen megdöbbentő eseményre jobb válasz az, hogy valaki "csinálta", mint az, hogy ilyesmi spontán megtörténhet. Ennek elemei az életkor korai szakaszaiban is megmutatkoznak. Az emberekben kialakuló világkép fejlődésének is van egy olyan szakasza, amikor azt gondolják a gyerekek, hogy mindent a "bácsik" csinálnak. Miként jön létre egy folyó? Jönnek a bácsik, és kiássák a medret. Később, persze helyére kerülnek a dolgok, de vannak, akiknél szerintem ez megmarad később is. Miként csapódik egy utasszállító egy felhőkarcolónak? Jönnek a gyíkemberek és a CIA segítségével megcsinálják.

Szerintem ezzel nincs is semmi gond, nem lehetünk minden tulajdonságunkban egyformák. Egyesek nem tudják lefutni a Maratont, mások meg nem tudnak elszakadni az összeesküvés elméletektől. A probléma szerintem nem ez.

Még az sem olyan nagy gond, ha olyan összefüggéssel számolják ki a vírus riasztás szintjét, amiről egy általános iskolás is látja, hogy értelmetlen. Bár ez már jelez némi hozzá nem értést, de mivel ezekről minden értelmes ember látja, hogy hülyeség, egy globális nevetésen kívül nagyobb bajt nem okoz.

A probléma ott kezdődik, amikor azok az emberek kezdenek el hülyeségeket mondogatni, akiknek az a feladatuk, hogy gondolkodjanak. Mert jelen pillanatban ez történik. A preprint szervereket például elárasztották a koronavírus szakértők. Hol voltak eddig? Talán a föld alatt, és onnan másztak elő a Necronomicon hívó szavára?

Például tessék megnézni mindenki kedvenc vitaminját, a C vitamint. Időről-időre eszébe jut valakinek, hogy ezzel váltsa meg a világot, ezért nem meglepő, hogy a hülyeségcunami első hullámával azok a híresztelések érkeztek, hogy a C-vitaminnal megálljt lehet parancsolni egy vírusnak. Még az influenzát sem állítja meg, de Pauling szelleme olyan erős, hogy ötven évvel a halála után is hisznek neki.

Ez a "régi jó dógokhoz" való visszanyúlás figyelhető meg a hidroxiklorokin esetén is. Lépten-nyomon bizonyítják, hogy teljesen hatástalan, de még mindig vannak orvosok, kutatók, akik újabb esélyt adnak neki, sőt cikket írnak belőle. Ha egy vadat lelőnek, ott kell hagyni döglötten, nem rugdosni előre, miközben hangosan kiabáljuk, hogy "még mozog, biztosan él".

Ha valaki hülyeséget mond, akkor nem védi meg a hírnév, a szakmai múlt és a számtalan kitüntetés. Ez történt ugyanis John Ioannidissel is. Évtizedeken keresztül, kérlelhetetlen alapossággal kutatta a módszertani buktatókat és leplezett le kutatókat. A felesége ráadásul a fertőző betegségek szakértője. Ketten együtt sikerült akkora batár nagy marhaságot összeírniuk, hogy az már fájt. Persze a szakmai közösség rákapott a cikkre, mint éhes pitbull a csupasz lábszárra és ennek megfelelően szét is cincálták az egészet. Pontosan azt csinálták vele, mint amit ő is csinált éveken át mások munkájával.

Igazából, ha valamiben nem vagyunk teljesen biztosak, jobb csendben maradni. Bevallom, nekem is sok téves elképzelésem volt a vírussal kapcsolatban, de sikerült megállnom, hogy ne csináljak hülyét magamból mindenki szeme láttára (bár más fronton biztosan találni egy-két ellentmondást az írásaimban). Igaz, rajtam nincs is nyomás, hogy követőket szerezzek és belőlük éljek.

Aki viszont kimondja véleményét ország-világ előtt, az óhatatlanul is állíthat hülyeséget. Történt ez Steve Salzberggel is, aki a saját szakterületén szerintem hasonló kaliberű ember, mint Ioannidis. Neki az fájlt, hogy ha 300 ezer embernek be lehet adni egy kísérleti gyógyszert, mert annyira biztonságos, akkor miért nem adhatnák be mindenkinek?

Viszont van egy nagy különbség Ioannidis és Salzberg között. Előbbi szaladt fűhőz-fához, hogy a többiek csúnyát mondtak rá. Lobogtatta a ráaggatott plecsniket, hogy ő márpedig valaki. Még ekkor sem volt képes elfogadni, hogy leszerepelt. Salzberg viszont felül tudta bírálni korábbi álláspontják, és képes volt elismerni, hogy tévedett. Ehhez is erő kell, egy olyan világban, ahol mindenki azt várja el, hogy a szakértők tévedhetetlenek legyenek. Ez legalább olyan fontos, mint "megmondani a frankót".

Szólj hozzá!

Címkék: filozofálás

Szokatlan programozási nyelvek a bioinformatikában

2020.08.02. 22:52 Travis.CG

Először is le kell fektetnünk, mit értünk szokatlan programozási e nyelvnek, hiszen az itt bemutatott nyelvek évek óta léteznek, ismertek. Lehet, hogy a ritka programozási nyelvek megfelelőbb cím lett volna.

Ami miatt mégis ezt a címet választottam, az a tény, hogy a tudományban is vannak divatok. Egy időben mindenki Perlben írta az aktuális okosságot, manapság inkább Python a menő. A C és C++ jelenlét konstansnak tekinthető, mert az elemzések gerincét végző programokat ebben írták, írják. Emellett előfordul az R és a Java. Előbbi a Bioconductor miatt, utóbbi platform függetlensége miatt. (Vagy mert a fejlesztők még abból az időből származnak, amikor a Java még menő volt.)

Azonban a nyelvek skálája szélesedett. Már nem csak olyan nyelvek vannak, amelyek a C-t, vagy a Java-t majmolják. Vannak olyan nyelvek is, amelyek új kihívásokra keresik a megoldást. (Eközben többen a Pythont majmolják, de ez már más kérdés.)

Vegyük például a Rust-ot, ami a biztonságos kódot tűzi zászlajára. Ez egy olyan cél, ami a bioinformatikában - ahol a kódminőség hagy némi kivetnivalót maga után - tényleg hasznos lehet. Az egyik programmal a BaseSpace-ről lehet letölteni adatokat, a másikkal a FastQ fájljainkat ellenőrizhetjük. De a 10x Genomics genom összerakó programjának, a Supernovanak is van egy Rustban írt része. Az egy sejtes genotípizáló eszközüknek a Vartrixnek viszont már sokkal nagyobb részét fejlesztették ebben a nyelvben.

A másik terület, ami a kódbiztonság mellett igen fontos a bioinformatikában, a többszálú feladatvégrehajtás. A Go nyelv pontosan ezt célozza meg. Nem meglepő, hogy létrejött a BioGO. A 10x Genomics ezen a nyelven is fejleszt, például a Lariat illesztőjüket. Rajtuk kívül a Grail nevű, korai tumor diagnosztikával foglalkozó cég használja előszeretettel a nyelvet, elsősorban a felhős infrastruktúra felügyeletére.

A harmadik bemutatott nyelv a Nim, amit Brent Pedersen használ előszeretettel. (Félelmetes programozó, érdemes követni a munkásságát) Ha egy mondattal szeretném bemutatni, akkor azt mondanám, olyan Python, ami natív kódot eredményez. A fordító érdekessége, hogy képes JavaScriptre is fordítani, amivel a webre költözést oldhatja meg egyszerűen a fejlesztő.

Heng Li pedig több nyelvet is összehasonlított, hogy melyik felel meg legjobban a következő projektjéhez. A fenti nyelvek mellett Crystalban is írt programot. Ezen kívül nem tudok más bioinformatikai projektet, amit ezzel a nyelvvel fejlesztettek volna.

Nem muszály és nem is érdemes egy nyelvnél leragadni, ha genomi adatokat akarunk feldolgozni. Itt is van fejlődés, még ha ez nem is olyan látványos, mint egy startup cégnél.

Szólj hozzá!

Címkék: bioinformatika

Összefogás COVID idején

2020.07.19. 23:45 Travis.CG

Bevallom, engem nagyon frusztrált, hogy sok ember vért izzadt, hogy a vírust megállítsák (vagy elviselhetővé tegyék a megújult helyzetet másoknak), miközben nekem a legfontosabb munkahelyi teendőim között az szerepelt, hogy a Dropbox mappámból fájlokat töröljek ki, hogy a megosztott tartalmak ne lépjék túl a mágikus 2GB-os határt.

Arra gondoltam, ha nem is tudok intubálni, talán az évek során összegyűlt annyi bioinformatikai tapasztalatom, hogy azt valamiképp mások rendelkezésére bocsáthassam. Ezért javasoltam a főnökömnek, hogy vegye fel a kapcsolatot a hazai COVID-19 csapat bioinformatikai fejeseivel.

A kapcsolat nagyon gyümölcsöző volt, mindkét fél sokat tanult a másiktól, kemény megfeszített munkával véghezvittük a lehetetlent és a megszerzett tudást az emberíség javára fordítottuk. Eközben egy kis bioinformatikus, akit mindenki lenézett, végül hőssé vált.

Ez a Disney-féle verzió. A valóság egy kicsit más volt, még erről az alsó szintről nézve is, ahol én vagyok.

Először elindult valami kollaboráció-féleség. Azt mondták, hogy szükségük lenne egy szerverre, ami vizuálisan megjeleníti az egyes virus genomok egymáshoz fűződő viszonyát. Valahogy úgy, ahogy a Nextstrain csinálja. Mivel a Nextstrain szerver felépítése teljesen nyitott, még tutorial is van, hogyan építsünk egyet saját magunknak, ezért szépen le is másoltam.

Az egész SSH kapcsolaton keresztül volt elérhető, viszont a vírus törzsek letöltése elég nehézkes volt, ezért nem is álltam neki, amíg nem pontosítjuk a célokat. A másik, ami megállásra bírt, hogy a Nextstrain szerveren saját elemzéseket is lehet definiálni, amiről szintén nem beszéltünk. Az elérhetőségeket elküldtem, és vártam, hogy mi lesz a következő lépés. Szokás szerint jött a Nagy Kuss.

Akkor tudtam meg, hogy a kollaboráció - ami létezett is, meg nem is - véget ért, amikor megláttam a megjelent kéziratot. Vagyis, valaki velem párhuzamosan megcsinálta ugyan azt. Illetve többet is, mert ott megvolt az összes törzs, és a teljes elemzés is.

Valami olyan homályos indoklás jutott vissza hozzám, hogy a magyar vírusoknak nem szabad publikus szerveren lenniük. Nem értem, mit titkolóznak, különösen, hogy az általam készített szerver nem volt publikus, csak az láthatta, akinek hozzáférést adtunk. A fenti kézirat is úgy tudott megszületni, hogy mások évek óta fejlesztik a Nextstraint, mások megosztják a teljes vírus genomokat, erre mi, Magyarok eldugjuk ezt a pár genomot, mert ez aztán az innováció melegágya. Mitől félnek annyira? Valaki megnézi őket, és levonja azt a következtetést, hogy a Magyaroknak még a koronavírusaik is szánalmasak? Emberek személyiségi jogai rendben vannak, de most egy olyan vírusról van szó, amit mindenki ki akar nyírni.

Persze mások is szerettek volna némi bioinformatikai kollaborációt. A Magyar Bioinformatikai Társaság egy körlevélben próbálta feltérképezni (az EBI hatására), ki milyen erőforrást tud felajánlani ehhez az új keresztes háborúhoz. A felmérés kimenetele ismeretlen számomra, de annyit tudok, hogy az ELTE büszkén hívta fel a figyelmet erre a kezdeményezésre, amiben részt vesznek.

Milyen érdekes, ez is az adatok megosztásáról szól, nem arról, hogy egy barlang mélyén kell gyönyörködünk művünkben, miközben azt mormoljuk: "Drágaszágom".

Szólj hozzá!

Címkék: filozofálás

Zsonglőrködés környezeti változókkal

2020.07.14. 17:41 Travis.CG

Szuperszámítógépes környezetben gyakran találkozunk a module load paranccsal, ha egy szoftver komponenst akarunk használni. Mi ez a parancs, mire tudjuk használni és hogyan fordíthatjuk saját hasznunkra?

A program nem csinál mást, csak a kiadott utasításoknak megfelelően kicseréli a környezeti változókat. Ez talán elsőre nem tűnik nagy dolognak, hiszen ott a Docker, Conda, de sok esetben egy virtualizációs megoldások csak elbonyolítják a helyzetet. Például képzeljünk el azt a felállást, amikor két olyan környezetet kell használnunk, ami két különböző Docker képfájlban van. De az is elképzelhető, hogy nem akarunk rendszergazdai jogokkal felruházni futó folyamatokat, mint ami a HPC környezetek esetén is tapasztalható.

A környezetek összevonása nagyon egyszerűen megy modules-al, de rosszul megtervezett modulok esetén továbbra is előfordulhatnak ütközések, míg Docker használatával ennek az esélye minimális.

A rendszer egyik gyengesége a Tcl/Tk környezethez való ragaszkodás, aminek történelmi okai vannak. Ez is csak azoknak jelenthet problémát, akik nem szeretik ezt az archaikus megoldást. Szerencsére létezik több alternatív rendszer, ami ezt lecseréli, például Lua-ra. Ebben a bejegyzésben csak a Tcl/Tk verziós megoldással foglalkozom.

Mivel elég régóta fejlesztett programoról van szó, az összes ismert csomagkezelőben megtalálható environment modules néven. Telepítés ezért gyerekjáték. Minden környezetet egy fájl reprezentál, amit Ubuntu esetén például az /usr/share/modules/modulefiles könyvtárban találunk alapértelmezetten. Általában nem érdemes nulláról kezdve megírni a fájlokat, inkább valamelyik, már létező fájlt kell módosítani, hogy a fájlok váza egységes legyen.

Milyen módon épül fel egy ilyen fájl? Először is kell egy #%Module, ami kínosan emlékeztet egy linuxos szkript fejlécre. Ez nem a véletlen műve. Utána jöhet egy verziószám.

A konvenció szerint ezután kommentek formájában érdemes egy rövid leírást adni magáról a modulról. Mivel csak ritkán olvassuk magukat a modul fájlokat, célszerű egy ModulesHelp függvényt is definiálni, ami szintén kiírja a szükséges információkat. Ezeket a modules help paranccsal jeleníthetjük meg.

Az összes többi bejegyzés szabványos Tcl/Tk utasítás. Készíthetünk ciklusokat, feltételes elágazásokat, bármit. A nyelv bemutatása túlmutat a cikk határain, ezért itt csak a legfontosabb dologra, a környezeti változók kezelésére koncentrálunk.

Bioinformatikai programok esetén az egyik legfontosabb környezeti változó, az elérési út, vagy "PATH". Amennyiben új elemet akarunk hozzáadni, az append-path parancsra lesz szükségünk. Utána a változó nevét kell megadni, amit Bash esetén a PATH, majd a hozzáadandó értéket, ami az elérési út.

append-path PATH "/home/user/mysoftware/bin"

Az adott modul eltávolítása után a bejegyzés is eltűnik. Tehát ha több környezetet használunk, és mindegyiknek saját bejegyzése van a PATH-ban, akkor a modul megszűnése csak az adott környezet bejegyzését törli.

A másik fontos parancs, az új környezeti változó felvétele, hiszen sok program azok alapján találja meg a konfigurációs állományokat vagy adatokat. A setenv parancs segítségével ezt érhetjük el. Szintaxisa nagyon hasonló az append-path-nál megismerthez. Először a parancs, majd a beállítandó környezeti változó neve, végül az értéke. A következő példa a STAR-Fusion számára állítja be az indexelt genom és a hozzátartozó annotációt tartalmazó könyvtár nevét:

setenv CTAT_GENOME_LIB "/usr/share/molbio/rna-seq"

Amennyiben készen vagyunk a fájlokkal, azonnal használhatjuk őket. A module load parancs segítségével betölthetjük az adott környezetet, csak a modul fájl nevét kell megadnunk. Ha már nincs szükségünk az adott környezetre, a module unload segítségével eltávolíthatjuk azt. Az elérhető modulok listáját a module avail mutatja meg.

Végezetül szeretnék pár megjegyzést tenni, amivel én szembesültem, amikor telepítettem és konfiguráltam a rendszert. Bash esetén nem szokott gond lenni, de más parancsértelmezők alkalmazásakor figyelni kell, hogy a modules inicializálása megfelelő legyen. Az /etc/profile.d könyvtárban található fájlok nem minden esetben futnak le, például zsh esetén. Nem megfelelő inicializálás esetén hiába vannak a modul fájlok a megfelelő helyen, azokat mégsem látja a felhasználó.

Ha több környezetet szeretnénk használni, akkor az environment-modules siet a segítségünkre. Segítségével átláthatóvá tehető a környezeti változók kezelése. Telepítése egyszerű, használata szintén. HPC környezetben előszeretettel használják, de saját rendszerünkre is telepíthetjük. Ez a bejegyzés nem érintett mindent, a program sokkal több lehetőséget rejt magában (például akár hierarhikusan is felépíthetjük a modulokat).

Szólj hozzá!

Címkék: rendszergazda

Cseppet sem objektíven: Just for fun 2020

2020.06.28. 22:17 Travis.CG

Az idei karantén világ egyik kellemes hozadéka volt a Just for fun compó, amit tényleg csak a móka kedvéért rendeztek. A releaseket interneten kellett elküldeni, majd egy YouTube streamen végignézni. Mivel az összes alkotásnak 30 másodperc hosszúnak kellett lennie, nem fenyegetett az a veszély, hogy elalszom közben, vagy a compó végére nem tudom, mit is láttam az elején.

Nem is tudom, hogy van-e értelme kritikát írni ilyen kompóról, ezért mindegyikről leírom, miért tetszett.

Az első a Transmission volt a The Bad Sectorstól, amit egy mikrokontollerre írtak. A mikrokontollerekre nehezebb kódot írni, mert sokkal több a limitáció. Mind a hardver felől, mind a létező eszközök részéről. Itt nem lehet azzal vádolni a készítőket. hogy az "OpenGL megcsinál mindent". Az Astroidea egy rég elfelejtett kódot adott be Astrocola néven. Ennek megfelelően 386-oson futott GUS alatt. Szerintem jó, hogy ezek a kódok még akkor sem vesznek el, ha nem adják ki őket, és ilyen ritka alkalmak egyikén láthatjuk mi is. Slyspy jó ötletet használt fel, mert egy régi Amigás demót elevenített fel vicces formában. Szerencsére a bemutatkozó videóból megismerhettük a demó hátterét is. A Dilemma Ocean's Drive azért volt jó, mert remek volt a hangulata és kellemes volt a zene is hozzá. Az Ümlaut Designtől szerintem egy trailert kaptunk, ezért nagyon felcsigázott, mit is akarnak bemutatni Function-ön. (Legalábbis azt gyanítom, hogy Function-ön mutatják be. Belsős információval nem rendelkezem.) A Rebels Function invitációja kihasználta a 30 másodperces limitet. A normál tempójú felvezetés után az összes part fél másodperc volt, és ennek megfelelően kedves kakofóniába torkollott. A The Bad Sectorstól kaptunk még egy demót, ami azért volt jó, mert Blueghost visszatért és új effektet használt, amit még soha azelőtt, ergó fejlődött.

Végül a demo1 tiborsaas-tól, ami azért is jó, mert első demó, rögtön győzelemmel. Az effektek teljesen rendben voltak, a zene passzolt a látványhoz. Reméljük még sok remek alkotást láthatunk tőle.

Szólj hozzá!

Címkék: demoscene

Lehet-e zenélni Linux alatt?

2020.06.17. 00:04 Travis.CG

Rövid válasz: nem igazán.

De miért? Először is, mit értünk zenélés alatt? Itt azt értem, hogy digitális hangszerekkel csak egy program segítségével az ötlettől a kész megvalósításig el tudunk-e jutni. Valahogy úgy, ahogy Windows alatt az FL Studioval, Abletion Live-al zenét készít az ember.

Linux alatt az egyetlen szóba jöhető program az LMMS. A program maga csodálatos. Tényleg hozza azt a minőséget és tudást, amit az ember elvár egy Linuxos programtól, miután megnézte a több éves múltra visszatekintő Windowsos alternatívákat. Ha el tudjuk fogadni a Gimpet Photoshop helyett, ha megbírkózunk a Blenderrel 3D Studio után, akkor az LMMS-el sem lesz gondunk.

A főbb részegységek itt is megvannak, az elérhető funkciók, ha nem is érik el a konkurensek színvonalát, de működnek, a felhasználói felületet pedig meg kell szokni. Ismerős a recept? Nem csoda, hiszen szóról-szóra ugyan ezt lehet elmondani a többi Linuxos tartalom készítő alkalmazásról is.

Akkor mégis mi a probléma? A probléma, a VST bővítményekkel vannak.

Az LMMS beépített zajforrásai hangszerei egyszerűen nem hangzanak jól. Bármit is csinál a felhasználó, úgy szólnak, mint egy bolhapiacon vásárolt gyerek szintetizátor. Még talán a GUS midi hangszerek, amelyek valamennyire elviselhetőek, de ez kevés szerintem.

A megoldás, hogy harmadik féltől származó hangszereket kell importálni a programba, és használni őket orrvérzésig. Ezek a VST pluginok. Gyakorlatilag azok a programok, amelyek nem kezelik a VST pluginokat, közröhej tárgyai. Ezért az LMMS is szépen beolvassa őket. Hurrá, akkor mi a probléma a bővítményekkel?

A probléma ott van, hogy programozói szempontból a VST plugin egy futtatható bináris fájl. Tehát minden oprendszer alá saját verzió kell, ami gyakorlati szempontból azt jelenti, hogy egy Windowsos bináris fájl GUI-val. Persze, van Mac és Linux alá is mutatóba valami, de többségében csak Windows alá van minden. Ezt vicces kedvű fejlesztők ki is használják és szükségtelen elemekkel tűzdelik tele azt. Bár egy profi még ezzel is tud kezdeni valamit:

De még ezzel sem teljesen lehetetlen a Linuxos LMMS használata, mert a Wine segítségével betölthetőek. A folyamat úgy néz ki, hogy az LMMS a VST előtt megpróbálja betölteni a Wine-t, aminek az inicializálása elég sok időt elvesz. A VST plugin időtullépés miatt dob egy hibát, a Wine összeszedi magát, elindul, és megjelenik a VST bővítmény felülete. Mazohisták ezt szokták használni, ha épp nincs a kezük ügyében szöges korbács.

Mindez eszi a memóriát, fogyasztja a processzort, és növeli az ősz hajszálak számát.

Arról nem is beszélve, hogy CentOS alatt csomagkezelőből nem is lehet felrakni. Az extra repoban megvan, de egy függősége nincs rendesen beállítva, ezért nem települ. Ubuntu alatt szépen felmászik a gépre, még a Wine-t is könnyedén lehet konfigurálni. Onnantól viszont nagyon elkeserítő, hogy csak pittyeg az egész.

Sajnos már nem emlékszem ki mondta, de egy demópartin elhangzott, hogy nem is az számmít, hogy milyen programot használunk, hanem milyen sample-ök vannak. Azt hiszem ez nagyon igaz.

Szólj hozzá!

Címkék: filozofálás

Slackware, biztos alapok

2020.06.09. 23:35 Travis.CG

Mivel a Minixel nem sok mindenre voltam képes a 20 éves laptoppal, arra gondoltam, kipróbálhatnék egy olyan rendszert is, ami több sikerrel kecsegtet. Ezért az elfekvő CD-im közül kiválasztottam egy Slackware 10-t. A későbbi verziókat már DVD-re írtam, a laptop pedig csak CD-t olvas, ezért a lehetőség adott volt.

A telepítés olyan volt, ahogy egy ilyen rendszertől megszokhattuk, illetve ahogy már megszoktam az évek során. Bebootol, és odadob minket egy parancssorba, ahol kézzel elvégezhetjük a partícionálást és aktiválhatjuk a swap területet. Utána a telepítő segítségével már beállíthatjuk a billentyűzet kiosztást, hálózatot és a felmásolni kívánt csomagokat.

A teljes rendszer 2.8G tárhelyet emésztett fel, ebben csak a KDE nemzetközi csomagok nem voltak benne. Grafikus felülettel 40MB memóriát evett, ami mérsékelt. A CPU használat 20% körül volt. Elég jól működött.

Végre meghallgathattam a laptop hangkártyáját működés közben. A doksi szerint Sound Blaster kompatibilis a hangkeltő eszköz, de FreeDOS alatt valami miatt mégis némák voltak a hangszórók (azóta találtam egy potenciális megoldást, majd kipróbálom). Már attól féltem, elromlott valami. A korai időkben a hangkártyát a felhasználónak kellett beállítani az Alsa programjait használva. Emlékszem, régen ezzel sok problémám volt, de most nagyon simán ment, magam is meglepődtem, hogy milyen hamar felcsendült a zene. Szóval zenehallgatásra lehet használni, bár a merevlemezen már csak 900MB hely van, ami nem sok demóparti zenei anyagát tárolhatja.

A fejlesztéshez van C, C++, Fortran, Perl, Python (de még csak a 2.2 verzió). Programozási házi feladatokat azért lehet csinálni rajta, az algoritmusok fejlesztését is gyakorolhatja rajta, aki akarja. Sőt, annak idején még a Java-t is szabadon terjeszthette mindenki, ezért találunk még a Sun idejéből való Java 1.4-t is.

Megnézhetjük a PDF állományokat, ami cikkek olvasásához hasznos. Kényelmesebb lehet, mint sok telefon képernyője.

Van egy teljes Tetex rendszer, úgyhogy tudunk írni könyvet, cikket, disszertációt LaTeX-ben. A magyar ékezetek használata kicsit nehézkes lehet, mert nincs teljes unicode támogatás, de a feladat nem lehetetlen.

Kipróbáltam, tudok-e szkennelni vagy nyomtatni az egyetlen 1.0-s USB csatolón keresztül, de nem sikerült. A Postscript nyomtatókat azért több erőfeszítéssel be lehetne állítani, de nem voltam elég kitartó.

Megpróbáltam netet is csiholni egy mobiltelefon segítségével, de az USB-s eszközt nem tudtam megetetni az ifconfiggal. Feltételezem egy kernel modul hiányzik. Mondjuk ha működne is a net, nem sok hasznos funkciót tudnánk elérni. Böngészőnek Netscape van, az SSH kliens teljesen elavult, bátrabbak IRC-hetnének, vagy FTP-ről tudnának letölteni.

LibreOffice teljesen hiányzik. Nem csak azért, mert ebben az időben még OpenOffice (StarOffice) volt a neve, hanem azért is, mert a Slackware-ek Abiword és Gnumeric fanok voltak.

Mivel a Linux játékok szempontjából ez idő tájt elég gyatra volt, ezért csak sakkozni próbáltam vele, de a grafikus felületű sakkprogram képtelen volt csatlakozni a gnuchess-hez. Szerintem a probléma nem teljesen orvosolhatatlan, ezért elméletileg sakkpartnernek is lehetne használni a gépet.

Gimp is van, de a mai digitális gépek felbontását figyelembe véve maximum egy animált GIF compóra elég a gép teljesítménye (Revision-ön szokott lenni).

A rengeteg hátrány ellenére ez volt az első rendszer, amivel potenciálisan alkotni is lehetne valamit. (Bár a FreeDOS-al készítettem az első 256 byte intrómat, ami valódi, kézzelfogható eredmény.)

Szólj hozzá!

Címkék: rendszergazda

Csak a móka kedvéért

2020.05.25. 21:57 Travis.CG

A demoscene egy remek hobbi, de egy idő után nagyon bele lehet bonyolódni, ami alatt azt értem, hogy indokolatlan mennyiségű időt és energiát lehet beleölni, az eredmény láttán mégis sokan csak fanyalognak. Például: ezt az effektet már láttuk X évvel ezelőtt. Esetleg: ezt meg lehet csinálni sokkal kisebb méretben is. De még olyan is előfodrulhatm, hogy azzal vádolnak meg, hogy nem kódolunk semmit, mert Y jatékmotort használtuk. Nem csoda, hogy sokan nem produkálnak semmit, még akkor is, ha megvan a megfelelő tudásuk hozzá.

Időről-időre emlékeztetni kell magunkat, hogy ez az egész mégis csak egy hobbi, amit azért csinálunk, hogy jól érezzük magunkat. De akkor is sok időt kell ráfordítani.

Ezért is jó a most következő Just For Fun compó, ahol összesen 30 másodperc időt kell feltölteni. A release mérete pedig nem lehet 16 MB-nál nagyobb. Tehát nem kell vért izzadni, hogy telenyomjuk a demót részletes tartalommal, mert nincs rá hely. Nem kell több száz effektet kitalálni, mert nincs idő rá, hogy bemutassuk. Optimalizálni sem kell, mert nem muszály beleférni 64k-ba.

Szóval, akinek van kedve, nyugodtan kipróbálhatja magát, a lényeg, hogy jól érezzük magunkat, és alkossunk. Részletes kiírást itt találhatunk.

Szólj hozzá!

Címkék: demoscene

Bioconductor annotáció készítés

2020.05.19. 23:38 Travis.CG

A Bioconductor remek kezdeményezés, a bioinformatikai elemzések egységes platformja, ahol könnyedén új komponensekkel bővíthetjük a rendszert. Nemcsak szoftver, hanem adat oldalon is bővíthető a rendszer, hiszen a különböző annotációk ugyan olyan fontosak a bioinformatikai munka során, mint az algoritmusok. De mi a helyzet, ha a vizsgált faj annotációja nem létezik a Bioconductor égisze alatt? (Tipp: nézzük meg a blog mottóját.)

Bizony, a Bioconductor amilyen hasznos szolgálatot tesz a humán és egér vizsgálatoknál, olyan használhatatlan más fajoknál. Pedig az EnsEMBL, UniProt, KEGG tele van rengeteg fajjal, csupán azt kellene megoldani, hogy ezek az adatok szabványos formátumban legyenek, hogy aztán a programok felhasználhassák azokat.

Szerencsére nem kell nulláról kezdeni a munkát, a Bioconductor ahhoz is segítséget ad, hogy elkészíthessük ezeket a csomagokat. Lássuk, hogyan is kell hozzákezdeni egy ilyen munkához.

A két legfontosabb csomag, amit használni fogunk, az AnnotationHub és az AnnotationForge. Ha szerencsénk van, csupán egyetlen parancsot kell kiadnunk:

makeOrgPackageFromNCBI(version="0.1", author="Travis <travis@fake.com>", maintainer = "Travis <travis@fake.com>", outputDir = ".", tax_id = "60711", genus = "Chlorocebus", species = "sabaeus")

A legfontosabb paraméter a tax_id. Ez alapján fogja ugyanis a rendszer az NCBI-ról letölteni az adott fajhoz tartozó adatokat. Ami még sok fejfájástól kímél meg minket, ha követjük az annotációs csomagok formátumára vonatkozó ajánlásokat. Például a csomag szerzője után <> közé az email címet is meg kell adni. Letöltés után mindent egy SQLite adatbázisba pakol, majd elkészíti a megfelelő csomagot. Ezt telepíthetjük is:

install.packages("./org.Csabaeus.eg.db/", repo = NULL, lib = "/usr/lib64/R/library")

Az utolsó paraméter nem kötelező, és szükség van írási jogra az adott könyvtárra. Sok esetben ennyi elég is. De, mint ahogy a tapasztalatok is mutatják, ritkán van jó napunk, a legtöbb esetben ennél többet kell dolgozni.

Ilyenkor nekünk magunknak kell a megfelelő adattáblát letölteni, majd formázni. Letölthetjük őket a BioMart-ból, UCSC-ből, vagy egyéb forrásból. Először is azt kell eldöntenünk, mi lesz az elsődleges azonosító. Ez lehet az NCBI vagy az EnsEMBL gén azonosító. Ez azért lesz fontos, mert minden adattáblánk ezen azonosító szerint lesz összekötve. Ez minden táblában az első oszlop kell, hogy legyen, és GID legyen az oszlop neve.

A második legfontosabb lépés, hogy mindegyik táblának, amit az adatbázis építéshez használunk, legyen értéke minden oszlopban. Sok esetben ez nem megvalósítható, ilyenkor célszerű a táblát több al-táblára osztani. A fejléc bármi lehet, de az első oszlop mindenképp a GID kell, hogy legyen.

Amennyiben GO adatokat is szeretnénk, úgy annyi megkötés van, hogy a táblánk három kötelező oszlopot kell, hogy tartalmazzon: GID, GO, EVIDENCE. Az első a gén azonosítónk, a második a GO azonosító, a harmadik pedig a bizonyíték, ami alapján a gént az adott ontológiával összekötöttük. Ezen felül bármilyen további mezőt megadhatunk.

Ha készen vannak a tábláink, el kell készíteni a csomagot:

makeOrgPackage(version="0.1", author="Travis <travis@fake.com>", maintainer="Travis <travis@fake.com>", outputDir=".", tax_id="60711", genus="Chlorocebus", species="sabaeus", ensembl=enstable, ucsc=ucsctable)

A paraméterezés megegyezik a makeOrgPackageFromNCBI-al, de kiegészül az egyes táblák nevével, ami a példában enstable és ucsctable néven szerepel. Megkötés nincs. Az elkészült csomagot a korábban bemutatott módon telepíthetjük.

Természetesen egy létező csomagot is vehetünk alapul, ha nem akarunk mindent más forrásból letölteni. Először érdemes megnézni, milyen adatok érhetőek el az AnnotationHub-ban. Ez az annotációs csomagokat kívánja egyesíteni egy kereshető formában. Használata számomra kicsit szokatlan volt, de cserébe egyszerű.

ah <- AnnotationHub()
res <- query(ah, c("go", "sabaeus"))
mydb -> res[[4]]

A query parancsnak bármennyi kulcsszót megadhatunk, ezek ÉS kapcsolatban lesznek. Az eredmény egy lista azokkal az adatbázis azonosítókkal, melyek megfelelnek a keresési kritériumoknak. Az adatbázis elérhető mezőiről az mcol parancs ad felvilágosítást. További részletekért érdemes megnézni az AnnotationHub dokumentációját.

 

Szólj hozzá!

Címkék: bioinformatika

Minix, az őserő

2020.05.10. 22:03 Travis.CG

Egy időben a prog.hu fórumon minden tejfeles szájú operációs rendszert akart írni, amihez csapatot toborzott. Ez alól természetesen én sem voltam kivétel. Utólag visszanézve ezeknek a kezdeményezéseknek a 99%-a elenyészett, a maradék egy százalék pedig egy poros CD tokban hever valahol a warez filmek mellett. De mégis, honnan szerezhet ehhez megfelelő tudást valaki?

A válasz Andrew S. Tanenbaum könyvében keresendő, aki oktatási céllal készített egy operációs rendszert, a Minixet. Az egyetem alatt az akkor még 10 floppy lemezt kitevő rendszert felraktam egy 386-osra, és azon tanultam meg a Unix alapjait.

A rendszer azóta sokat fejlődött, újabb szolgáltatásokkal bővült, ezért itt az ideje, hogy megnézzük, mennyire használható egy 20 éves laptopon.

Bár a floppys telepítés még elérhető, én mégis a CD verziót választottam. A telepítés simán ment, viszont a telepítés utáni teendőket manuálisan kell végrehajtani. Például, ha új felhasználót hozunk létre, akkor a home könyvtár root tulajdonú, nekünk kell beállítani. A támogatott hardverek száma kevés, még magyar billentyűzet kiosztás sincs alapból. Internet támogatás van, de csak minimális számú hálókártyához.

Viszont meglepően sok csomag található a rendszerhez. Sokan, akiknek csak egy minimalista webkiszolgáló kell, Minixet használ, ezért van Apache, Python (igaz, csak 2.7 verzió), PHP. Sőt, X kiszolgáló is van! A programok nagy részét csak neten keresztül lehet telepíteni, de a csomagkezelő erről az FTP szerverről szerzi be a szükséges fájlokat. Elméletileg ezek CD-re írva is telepíthetőek, ezt ki is fogom próbálni.

Pár csomag elérhető a telepítő CD-n is, mint a C fordító, Python, Perl. Ezekkel már lehet kezdeni valamit, aki nagyon elhivatott. Nekem egy hello world szintű program telepítése is gondot okozott. Először, mert nem találtam a magyar billentyűzeten olyan fontos karaktereket, mint a #. Utána az ld-t hiányolta a fordító.

Apropó fordítás! GCC nincs, helyette az LLVM-el kell beérni, és mint említettem, Pythonból is csak az elvault verzió érhető el.

A rendszer nálam stabilan működött, de üresen is elég sok erőforrást vett el. A top szerint az 500 MHz-es CPU 50%-on pörgött. A fórumok tanúsága szerint nem ez a fő prioritás, hiszen egy oktatási céllal készült operációs rendszerről van szó. Ha a gépem netre tudnám kötni, valószínűleg jobban kihasználhattam volna a rendszer lehetőségeit.

Elsősorban azoknak jelenthet alternatívát, akik meg akarják tanulni a Unix környezetet, vagy a rendszer programozást.

Szólj hozzá!

Címkék: rendszergazda

Pan megmenti a világot

2020.05.03. 08:03 Travis.CG

Eddig elég sok negatív dolgot írtam az intézeti rendszergazdákról. Álmomban sem gondoltam volna, hogy egyszer egyikük megoldja egy problémámat. Pedig most pontosan ez történt!

Elkészültem a programmal, aminek az lenne a szerepe, hogy koherenciát csempésszen abba a kaotikus világba, amit úgy hívnak pályázati adminisztráció. A program egy lokális adatbázist használ, aminek az a feladata, hogy megkönnyítse az életemet, de ezt valami Microsoftos mellékízzel teszi.

A fejlesztői gépen egy Visual Studio 2015 volt, adatbázis kezelőnek pedig egy SQL Server 2012. A program elkészülte után megpróbáltam a Publish menüponttal egy telepítőbe tuszkolni mindent, de elsőre nem sikerült. Mint megtudtam, alapértelmezetten nem rak bele minden szükséges komponenst a telepítőbe. Miután kiválogattam, hogy a PDB fájlokat, DLL-eket is tegye mellé, akkor már használható lett az eredmény.

Gondoltam kipróbálom a telepítőt a feleségem gépén is, mert azon nincs fent a több giga Visual Studio, közelebb áll az adminisztrátor konfigurációjához, aki majd használni fogja a programot. Ekkor szembesültem vele, hogy a futtatáshoz kell egy .Net Framework, és egy SQL Server LocalDB.

Szerencsére be lehet állítani, hogy milyen függőségei vannak a programomnak, és azokat a telepítő próbálja meg letölteni. A .Nettel még nem is volt probléma, de a LocalDB nem akart települni. Illetve települt, de utána hibaüzenetet adott, a kész program meg kivételeket dobott, hogy a szervert nem találja.

A Stackoverflow szerint a baj az volt, hogy a letölteni kívánt függőség megváltozott ahhoz a verzióhoz képest, amivel fejlesztettem. Ezt én nem értettem. Hogyan tudna megváltozni egy több, mint nyolc éves program?

Közben a programot egyre inkább használni akarták, én meg kapcsolatba kerültem egy fertőzött emberrel, amitől az intézet vezetősége kitiltott. Kénytelen voltam a telepítést az intézet rendszergazdáira, azon belül is Pan-ra bízni. Mondanom sem kell, ő sem jutott közelebb a megoldáshoz.

Ezért készítettem még egy telepítőt, de most azt állítottam be, hogy ne töltse le a komponenst, hanem csapja a programom mellé. Erre több, mint nyolc hibaüzenetet dobott, hogy neki azok nincsenek meg. A Microsoft dokumentációja szerint nekem kell letölteni azt a komponenst, aminek az URL-je ott van a Visual Studio könyvtárhierarchiájának mélyén, és amelyiket a programom telepítésekor le is tud tölteni.

Rendben, akkor letöltöm én. A dokumentáció arra viszont nem tért ki, hogy mind a 32 bites, mint a 64 bites verziót le kell tölteni, és elhelyezni az XML-ek mellett x86, illetve x64 alkönyvtárakban, és akkor a Visual Studio mellékelni tudja. A telepítő már több száz megabájtra duzzadt.

Ez sem jött be. Azt a hibaüzenetet kaptuk, hogy "...SQL Network Interfaces, error: 50...". Ezt sem tudtam értelmezni, mert nem használtam hálózatot, lokális adatbázist adtam meg kapcsolatként. Közben Pan kiderítette, hogy hiába lesz telepítve az SQL Server, a program képtelen lesz használni az adatbázist, kivéve, ha előtte az SqlLocalDB parancssoros eszközzel létre nem hozzuk az adatbázis bejegyzést. Mi van? Nem ezért van a telepítő? Nem az lenne a feladata, hogy a felhasználónak ne kelljen parancssorban bogarászni?

Egyébként ez a OneClick telepítő megérne egy külön bejegyzést. Fogja az elkészített programot, és kérdés nélkül elrejti a felhasználó AppData könyvtárának a bugyraiba, olyan intuitív elnevezésekkel, mint 8342-12312-74. Mikor megkaptam a hibaüzenetet, győztem megkeresni a program helyét.

Hanem, amikor elkészült az adatbázis bejegyzés, települt az SQL Server, még mindig nem lehetett használni a programot. Nem stimmelt az SQL Server verziószáma! Ekkor tudtam meg, hogy három féle verziószáma van a programnak. Van egy, amit mi, halandók használunk: SQL Server 2012, van egy belső adatbázis verzió, ami 706, és van még egy verziószám, amit akkor ír ki, ha parancssorban turkálunk benne, ami V11. Tényleg szükség van minderre? A hibaüzenet szerint, nekem 852-es adatbázisra van szükségem. A táblázat alapján ez SQL Server 2016!

Mikor Pan először kezdett beszélni nekem arról, hogy a programom a 2016-os adatbázist vár, azt hittem túl sokat ivott. Hiszen nekem SQL Server 2012-m van. Csak tudom, mi van a gépemen, még a Visual Studio is kilistázza nekem az elérhető szoftver komponenseket, és ott csak a 2012 szerepel.

Azért megnéztem, mi van a gépemre telepítve. Legnagyobb meglepetésemre volt SQL Server 2008, 2012, 2016 is. Amikor elkezdtem használni a LocalDB-t, ott valahogy a 2016-t kezdte el használni, bár nem emlékszem, hogy felajánlotta volna, melyik verziót akarom használni. A Visual Studio OneClick telepítője viszont csak a 2012-t ajánlja fel, mint telepíthető függőséget.

Hanem ekkor még nem volt vége. Pan hiába rakta fel a 2016-os verziót a célgépre, az még mindig nem működött. Ugyanis ez a szemét SQL Server képes különböző verziókat egy helyen tárolni. Mikor Pan 2012-es verziójú adatbázist hozott létre a 2016-os SQL Serverben, akkor a programom még mindig nem működött. Amint rájött erre, és javította, azonnal futott minden.

Mindig is tudtam, hogy nem értek a Windows-hoz, de azt hittem képes vagyok megoldani bármilyen problémát. Itt viszont semmi nem az volt, aminek látszott. Teljesen érthetetlenek számomra a telepítő készítés logikája, az opciók, az alapérelmezett beállítások. Semmit mondó hibaüzenetek és szürreális megoldások. Pan mégis átlátta az egészet és végigevickélt rajta. Egy rossz szavam sem lehet rá ezután.

Szólj hozzá!

Címkék: rendszergazda

Mindenki szófa scener

2020.04.23. 22:49 Travis.CG

Emberek veszítik el szeretteiket, munkanélküliség, sosem látott gazdasági recesszió. túlterhelt kórházak, szükségállapot, kijárási tilalom több országban. Mindeközben mit csinálnak a demoscenerek? Természetesen partit tartanak, és buliznak.

Sokáig úgy tűnt, hogy a demó partik gerincét képező Revision bedobja a törölközőt, és elmarad, de a kockákat egy világjárvány nem állítja meg. Amíg áram és net van, addig parti is lesz. Csak kicsit máshogy.

Az otthonunk ugyanis már nem csak munkahely, iskola, mozi, edzőterem, hanem immár egy demó parti helyszíne is. Ami azt jelenti, hogy igazából egyik sem teljesen, ami kihat az élményre. Például ha a fotó kompó egybe esik az esti fürdetéssel, akkor az eredmény, hogy egyik sem sikerül igazán.

Én két dologgal készültem. Az egyik egy fotó volt, amit nem adtak le, a másik egy videó, ahol nem volt kép. De ezzel egy kicsit előre szaladtam.

Tehát kezdjük az elején. Egy héttel Revision előtt eszembe jutott, hogy akár csinálhatnék is valamit. Futtatható stuff szóba sem jöhetett, de a szokásos videó+fotó kombináció kivitelezhetőnek tűnt. Találtam egy félig használható zenét Shamen tíz éves CD-jén. Azért mondom, hogy félig használható, mert egészen jól indult, de három perc után témát váltott. Mivel a korábbi videómnál is az volt a legfőbb kritika, hogy túl hosszú, ezért itt elvágtam a zenét, hogy teljesen használható legyen.

Három nap alatt össze is vágtam az anyagot és feltöltöttem. Egy ponton nagyon aggódtam, mikor kérték a zeneszerző lakcímét. Ezt nem tudtam, de nélküle nem engedték feltölteni a cuccot. Végül beírtam valamit, majd jeleztem a szervezőknek, hogy mit tettem.

A fotóra egy 360 fokos kamera képét választottam. Bevallom, nem számítottam semmi galibára, de tudtam, hogy nem egy égbekiáltó eredmény.

A szombati kompók este 6-kor kezdődtek. A fotók egy része nagyon jó volt, de azt nem értettem, ha előválogatás volt, akkor a szőnyegről készült kép miért maradt benne? Végül is mindegy, de azért elkeseredtem egy kicsit. Az animációknál sem lett jobb kedvem. Nosfe ismét egy zajdemót adott be, és én első alkalommal örültem neki, hogy otthonról nézhetem ezt a rettenetet, és közel a hangerő szabályozó.

Majd jött az én entry-m, de a streamen csak valami feketeség látszott. Egyesek szerint még így is jobb volt, mint a zajdemó, de ez nem sok vigaszt jelentett. Majdnem fél perc lement, én meg úgy éreztem magam, mint 2010-ben, bár akkor hang nem volt. Szerencsére leállították a vetítést és elkezdték előről, de addigra annyira elment a kedvem mindentől, hogy tovább már nem is néztem, inkább olvastam.

Másnap azért ránéztem a streamre. A 8K elég vérszegény volt. A feltöltött alkotások böngészése közben még nekem is feltűnt, Jézus milyen aktív volt. Időről-időre feltűnik egy feltűnési viszketegségtől szenvedő valaki, aki a pocsék releaseket azzal ellensúlyozza, hogy egy ideológia mögé bújik. Ilyen volt annak idején a Horror Terror Elite Legion, most meg a Love Jesus.

Aztán elkezdődtek az Amiga demók. Igazából a vége felé elég hangulatos alkotások voltak, de nem ültem a székem mellé. Amit nagyon sajnáltam, az a Titan demó. Olyan ígéretesen indult, aztán ellaposodott.

A PC demók jó része valami keretrendszerrel készült. Még Godot is volt. A legrosszabb mégis az volt, hogy szinte lehetett látni, mely alkotások készültek saját motorral. Még a Unity demók is, amelyek öt éve még tehetség pótlásnak számítottak, olyan minőségű eredményt produkálnak, hogy csak nézek.

Nem tudom, mit is gondoljak az idei Revision-ről. Egyrészt jó, hogy a szervezők nem adták fel, és sikerült valamit összehozniuk. Nem látok a színfalak mögé, de szerintem elhivatottság kell ahhoz, hogy úgy is végrehajtsák az emberek a feladatukat, hogy nem felügyelik őket. Másrészt nem tudtam rákoncentrálni a compókra, annyi minden történt.

Szólj hozzá!

Címkék: demoscene

Közbeszól a valóság

2020.04.05. 22:35 Travis.CG

Egyik demópartin, mikor megkérdeztem valakit, hogy miért nem csinált produkciót, a következő válaszolta:

- Most real-ben nyomtam, nem volt időm molyolni.

A beszélgetés alakulása közben vált világossá számomra, hogy a mindennapi élet viszontagságai a "real", és nem az észlelt valóság. Egy pillanatra ha elfelejtjük a képzavart, egyet érthetünk, hogy néha fel kell kötni a gatyát, ha úgy akarunk véghez vinni valamit, hogy közben más frontról érkező támadásokat is vissza kell vernünk. Mint történt a most bemutatásra kerülő cikkünknél is.

Az első bonyodalmat a csapat bioinformatikusának eltűnése jelentette. Elhagyta az országot és beszüntette a kommunikáció minden formáját. Illetve az elején még egy-két hét csúszással válaszolt, majd a csúszások csak hosszabbodtak, hosszabbodtak, míg végül a végtelenhez nem kezdtek tartani.

Én vettem át a helyét és szomorúan tapasztaltam, hogy még a szekvenciák jó részét is magával vitte, hogy majd "dolgozzon" rajtuk. Néhány hibásan elnevezett szekvencián kívül nem sok maradt, no meg az ábrák, amelyeket valahogy elkészített. Jegyzőkönyv nélkül nehéz volt bármit is kiokoskodni.

Mikor beszálltam a projektbe, először az elkészült kéziratot kellett megnéznem, hogy azok elég részletesek-e, helytállóak-e a következtetések. Mivel ez is egy leíró jellegű cikk volt, elég hamar elvesztettem az érdeklődésemet. Pár választ odafirkantottam a kézirat szélére és letudtam.

Ilyen könnyen nem úsztam meg. Szépen, finoman megkértek, hogy nézzem át még egyszer. Még egyszer átnéztem, de továbbra is egy leíró jellegű cikk volt. A kéziratban szerepelt négy kladogram Salmonella törzsekkel. Az első a teljes genomok alapján készült. A második a központi gének alapján. Volt egy, ami az egyedi géneket vette alapul, végül egy, ami a genomi szigetek viszonyait tükrözte. A kladogrammok teljesen különböztek egymástól, nem mutattak sem időbeni csoportosulást, sem földrajzi izolációt. Négy teljesen különböző reláció volt.

A szöveg is ezt tükrözte. Mindegyik kladogrammról volt egy fejezet, és leírta, hogy ott mit lehet látni. Nem értettem, mi a célja a publikációnak, miért készült, miért kell ennyi különböző módszert belevenni, ami semmi érdemi konklúziót nem tartalmaz.

Ezért tartottunk egy megbeszélést, ahol felvilágosítottak a dolgok hátteréről. Megjelent ugyanis egy cikk, ahol európai Salmonella törzseket vizsgáltak, majd a cikk zárásaként levonták azt a következtetést, hogy a svájci törzsek magyar eredetűek, sőt egész Európát magyar Salmonella törzsek fertőztek be. Következtetésként mindenért mi vagyunk a hibásak.

Ezen néhányan nagyon felhúzták magukat. Egyesek odáig mentek, hogy olyan kijelentéseket tettek, miszerint "Magyarország támadás alatt áll". Eleinte jól is hangzott, hogy az országot az én kis számítógépem védi meg a gonosz felforgató elemektől, valahogy úgy, ahogy affektáló Hujber Ferenc is tette a katonai hírszerzés hackereként. A megbeszélés további részeként szidtuk a svájciak anyját, apját, az editort, aki átengedte a cikket, meg a bírálókat.

Tehát a cikk igazi célja az volt, hogy bebizonyítsuk, a svájci törzsek nem magyar eredetűek. Ezért volt a számtalan módszerrel elkészített fa. Bármelyiket is néztük, a két ország törzsei messze voltak egymástól. Ráadásul mi több törzset használtunk fel, aminek az egyik következménye az lett, hogy szerológiailag Salmonella Infantisnak tartott törzsekről kiderült, genetikailag semmi közük az Infantisokhoz.

Az első feladat az volt, hogy elő tudom-e állítani az ábrákat, a rendelkezésre álló adatokból. A teljes genomok szekvencia fájljai megvoltak, de az hiányzott, hogy mely géneket tekintették központinak, és melyeket egyénieknek. A genomi szigetekről nem is beszélve.

Itt tennék egy kis kitérőt. Ha fogunk egy csomó baktérium törzset, lesznek gének, amelyek minden törzsben előfordulnak, és lesznek, amelyek csak a törzsek egy részére jellemzőek. Tehát minden gén kaphat egy százalékos értéket, hogy a törzsek mekkora hányadában fordul elő. A központi, vagy core gének, amelyek a törzsek 90%-ban előfordulnak, míg az egyedi, vagy cloud gének csak maximum 10%-ban. Ezek a meghatározások igen képlékenyek, mert nem csak a százalékos határok szubjektívek, hanem az is, mikor tekintünk hasonlónak két gént. Melyik az a százalékos határvonal, amikor azt állíthatjuk, hogy a gének szekvenciái egyformák?

Sőt, van még egy probléma, ha már így belemerültünk a baktérium genomok elemzésébe. Ha csak a genomhoz feltöltött annotációt nézzük, akkor nem találunk meg mindent gént. Ugyan annak a génnek egy másik törzsben  másik neve lesz. Ezt úgy oldottuk meg, hogy minden baktérium genomot újra annotáltunk egységes módon.

A helyzetet tovább bonyolította, hogy a fák alapját képező többszörös illesztést két különböző módon is el lehet készíteni. Fogom a gének szekvenciáit és összefűzöm őket egyetlen virtuális szekvenciává (ezt a módszert követték a svájciak), vagy nem fűzöm össze, és a Mauve-ra bízom, hogy megoldja a problémát. Mondanom sem kell, két teljesen különböző eredményt kapunk.

Mivel a teljes genomok alapján készített fák megegyeztek azzal, amit én készítettem, feltételeztük, hogy a többi fa is ugyan olyan lenne, ha meglennének a szekvenciák. Úgy gondoltuk, a módszer reprodukálható.

Sajnos az összes képet módosítani kellett, mert a nevezék nem tetszett a csapatnak, más betűtípust akartak és módosítani akarták a kiemeléseket is. Mivel nem tudtam újra előállítani a képeket, kénytelen voltam Gimp-el átrajzolni a már meglévő ábrákat. Ez egy rendkívül unalmas meló. Már nem éreztem magam szuper hekkernek, csak egy szerencsétlen flótásnak, akinek hülye feladat jutott. Magyarország becsületének védelme egy grafikus programon múlik.

Igazából letölthettem volna a szekvenciákat, és elkészíthettem volna újra a fákat, de a többszörös illesztések több napot vettek volna igénybe, míg a Gimp-el egy óra alatt megvoltam. Mivel tapasztalatom szerint az ábrákkal mindig akad pepecselni való, ezért előrelátó módon a feliratokat külön rétegekbe raktam. Ezért a második, harmadik, sokadik módosítás már könnyen ment.

Ahogy teltek az idők, a kézirat gyökeresen megváltozott. A szerkezete megmaradt, továbbra is különböző módszerekkel elkészített fák voltak benne, de ezek kezdtek egy egységes koncepció köré csoportosulni. Az ábrák is egységes stílust kaptak. Összeállt az anyag. Tartottunk egy utolsó megbeszélést, ahol ismét elszidtuk a svájciak anyját mindennek, lehülyéztük őket, mindezt olyan magas röptű stílusban, ahogy csak az akadémiai szférában lehetséges.

December 24-én kaptuk meg a bírálók anyagát. Azt szerették volna, ha több törzset veszünk be a vizsgálatokba és megnézzük az antibiotikum rezisztencia géneket is. Eredetileg ezt nem akartuk, de ezek után kénytelenek voltunk ezt is megcsinálni. Egyedül a határidővel volt probléma, mert egy hónapot adtak minderre, ami figyelembe véve az Ünnepeket, tarthatatlannak bizonyult. Rögtön halasztást kértünk, amit meg is kaptunk.

Közben újabb bonyodalom történt, az egyik szerző balesetet szenvedett, így az ő segítségét nélkülözni kellett.

Letöltöttem az új baktérium szekvenciákat, hozzácsaptam a korábbi genomokhoz, amelyekkel korábban dolgoztam és elkezdtem az elejéről mindent. Most már meg kellett csinálni az összes illesztést, annotálást. Már nem volt elég Gimpezni. De a sok munka mellett volt ennek egy előnye is: Nem kellett a régi ábrákra, elnevezésekre támaszkodni, ezért minden szekvencia, annotáció, kép, egységes nevezéket kapott. A szekvencia fájl neve, azonosítója ugyan az lett, később ez a név jelent meg a fákon is. Ezzel eléggé fel tudtam gyorsítani a munkát.

Ennek során megszegtem az egyik elvemet, miszerint nem használok szóközt fájlnevekben, de azt hittem sokkal egyszerűbb lesz a munka. A munkafolyamat nagy részén igazam is volt, a dolog akkor bukott meg, mikor a Roary képtelen volt azokat a fájlokat beolvasni, amelyek szóközt tartalmaztak. Ezt leszámítva, nem volt fennakadás, a neveket végig lehetett követni a munkafolyamat teljes hosszán.

Azért aggódtunk egy kicsit, hiszen említettem, hogy a központi és egyedi gének meghatározása elég szubjektív. Félő volt, hogy eltérő eredményt kapunk, és az egész diszkussziót új alapokra kell helyeznünk. Szerencsére az új fák nagyon hasonlóak lettek, csupán több törzset tartalmaztak. A svájci-magyar kapcsolat továbbra sem tűnt valószínűnek.

Tartottunk egy megbeszélést, ahol megvitattuk az új eredményeket. A vége felé ismét szóba került a svájciak anyaja, apja, és konstatáltuk, hogy a bírálók (akik bizonyára svájci szimpatizánsok) terve nem jött be, nem tudnak megállítani minket. Már csak az antibiotikum rezisztencia rész volt vissza, de abban nekem nem volt szerepem. Még az ábrák végső formáját sem kellett megcsinálnom, aminek örültem.

Hanem, az antibiotikum rezisztencia kapcsán az egyik szerző észrevette, hogy a magyar törzsekből hiányzik néhány olyan gén, amelyek létezéséről egy korábbi publikációban írtunk. Kiderült, hogy a magyar törzsek szekvenciái hiányosak. Néhány kontig hiányzott ahhoz képest, mint ahogy annak idején feltöltöttem az NCBI-ba.

A helyzet az, hogy a munka legelején, mikor átvettem a volt kolléga fájljait, nem ellenőriztem teljesen a szekvenciákat az NCBI-ban található verziókhoz képest, csak megnéztem, mekkora a fájlok mérete, az meg nagyjából stimmelt, nem foglalkoztam a dologgal. Ez elég súlyos hiba volt a részemről, még szerencse, hogy nem a bírálók vették észre. Tehát még egyszer letöltöttem mindent, összeraktam a genomokat, annotáltam őket, felépítettem a fát. Viszont ez már koránt sem volt akkora munka, mint korábban, mert Jupyterben volt a teljes elemzés, dokumentálva minden lépés. (Mikor az egyik bíráló arról beszélt, hogy a módszerünk nem megismételhető, akkor megkapta a linket.) Csupán kicseréltem a szekvenciákat egy könyvtárban, és mondtam, hogy futtasson le mindent.

Viszont az eredmények láttán majdnem hagyatt estünk. A svájci és magyar törzsek minden egyes elemzésben szépen együtt klasztereződtek. Egészen pontosan a magyar törzsek két csoportra oszlottak, az izolálás idejétől függően, és az újabb izolátumok tényleg a svájciakkal egy csoportba kerültek.

A csapat becsületére legyen mondva, ezután nem szidtuk a svájciak anyját, hanem elfogadtuk az eredményeket. Ezekért a pillanatokért szeretem a tudományt, amikor nem a prekoncepció, az érdekek alapján vonunk le következtetést, hanem a színtiszta adatok alapján. Nem próbálták rám erőltetni, hogy "használjunk másik programot", "másik statisztikát". Nem volt vádaskodás, hogy "biztos elszúrtad", "ez nem lehet". Át kellett írni mindent és a csapat ezt professzionálisan meg is tette. Elküldtünk mindent, mire meg is jött a válasz, hogy a bírálók mindent rendben találtak. Hurrá!

Hanem a befektetett munka miatt a szerzők sorrendje megváltozott. Emiatt mindenkitől beleegyező nyilatkozat kellett, hogy ehhez hozzájárul. Attól a bioinformatikustól is, aki beszüntette a kommunikációt. Ekkor felmerült a lehetőség, hogy ha nem érkezik válasz tőle, akkor kihagyjuk a cikkből. Ez nekem nagyon nem tetszett. Én sem szeretem, ha engem hagynak ki, ezért ahol lehetett védtem az érdekeit.

Ezzel sikerült is jól magamra haragítani pár embert. Ha ugyanis ki akartunk volna hagyni valakit, akkor a cikket vissza kellett volna vonni, majd újra beadni a módosított szerzőkkel. Kezdhettünk volna a teljes procedúrát előről. Ezért azt javasoltam, hogy mi lenne, ha mégsem változtatnánk meg a szerzők sorrendjét. Nekem estek, hogy miért védem azt, aki "ennyire hátráltatta a cikk megjelenését", meg "miért nem képes válaszolni".

Csak halkan jegyzem meg, hogy aki a leghangosabb volt, az egy korábbi cikkünknél szintén hátráltatta egy évig a publikálást, mert családi zűrjei voltak. Elég gyorsan elfelejtette ezt.

Egyébként csupán pragmatikus célok vezettek, hiszen ha vissza kell vonni a cikket és újra beadni, akár az is megeshet, hogy az új bírálók elkaszálják a cikket, és az mindenkinek rossz lesz. De mások ezt nem látták, nekik fontosabb, hogy első szerzők legyenek. (Nekem nem fontos, meg is látszik :-)

Szerencsére az elveszett munkatárs végül válaszolt, és nem kellett drasztikus dolgokhoz folyamodni. Aztán elért minket is a világjárvány, a cikk utolsó simitásait már otthonról végeztük.

Ennek a munkának rengeteg tanúsága volt számomra. Először is, ahogy Richard Marcinko is megmondta: Soha ne feltételezz! Ha kapsz egy fájlt, nem feltételezed, hogy jó. Ha látsz egy ábrát, de semmi leírást róla, akkor nem gondolod, hogy "biztos X-el készült". Második tanúság: Ha valamit rendesen is meg lehet csinálni, akkor úgy csináld, még akkor is, ha ez több időt vesz igénybe. Ha mindjárt az elején vettem volna a fáradságot, hogy rendesen elnevezem a fájlokat, elkészítem a munkafolyamatot, akkor megkíméltem volna magam egy csomó Gimp-es bohóckodástól. Végül pedig felejtsük el a prekoncepciókat. Itt mi meg is tettük, de mikor először megláttam az új eredményeket, féltem, hogy nagy veszekedés lesz miatta. Szerencsére a genetikai eredményeket a tőlem függetlenül végzett antibiotikum rezisztencia vizsgálatok gyönyörűen alátámasztották.

Szólj hozzá!

Címkék: publikáció

Enterprise 128, első benyomások

2020.04.03. 23:45 Travis.CG

Az Enterprise 128 régóta egy vágyálom számomra. Gyerekként a gépeket nem fejlesztettük, hanem újab vettünk. Ezért az egészséges versenyszellem keretében nem azzal fejeztük ki felsőbbrendűségünket, hogy semmitmondó processzor paraméterekkel dobálóztunk, hanem félig lehunyt szemmel kimondtuk gépünk nevét.

Ebben a - mai szemmel nézve nevetséges - versenyben a legtöbb gép 64 kilobyte memóriával volt ellátva. A következő nagy ugrás a 128 kilobyte-os gépek voltak. A C128 és az Enterprise. Az Amiga már akkor is a király kategória volt, azok nem versenyeztek mikroszámítógépekkel, hanem különböző bővítő kártyákkal felvértezve egymással mérték össze erejüket.

Én erről akkor semmit sem tudtam. Nem jártam klubbházakba, copy partikra. Számomra az informatika fejlődéséről egy műszaki bizományi kirakata adott felvilágosítást, ahol az elérhető legjobb gép az Enterprise volt. Szép, színes gombjai voltak, beépített joystick, sztereo hang, és nem utolsó sorban 256 szín. Hazafelé az iskolából mindig megálltam a kirakat előtt és megnéztem a gépet. Aztán a gépet eladták, én meg még évekig játszottam a C64-el, majd jöttek a PC-k. Az Enterprise feledésbe merült.

Mikor megismerkedtem a demoscene-vel, ahol nem nézik hülyének az embert, mert használhatatlan gépeket programoznak, ismét felrémlett bennem, hogy akár még szerezhetnék is egy ilyen gépet. Az idők viszont megváltoztak, gyakran tetemes pénzt kérnek el ezekért a gépekért, mert retro. (Ez a retro őrület azért kicsit túlmegy a józan ész határain. A legdurvább eset ezzel kapcsolatban, mikor egy bolhapiacon ezer forintot akartak elkérni egy kicsi, koszos gumilabdáért, mondván, hogy ez nem gyerekeknek van itt, hanem gyűjtőknek.)

Nem akartam egy fél vagyont egy Enterprise-ra költeni, amit még a maga idejében sem vásároltak, miközben Grass azzal dicsekszik nekem, hogy valami ócskásnál ötezerért talált egyet. (Ilyenkor bezzeg nem gondol rám.) Ezért csak különösebb cél nélkül böngésztem a különböző weboldalakat, eredménytelenül.

Azért néha nekem is lehet szerencsém. Találtam egyet, ami ha nem is ötezer volt, de az a kategória, amire azt mondtam, hogy "egye fene". (A feleségem inkább megrökönyödött, hogy milyen hülyeségeket vásárolok, de ez egy másik kérdés.) Így lettem egy Enterprise boldog tulajdonosa.

Azért a gépről igencsak hiányos ismereteim voltak, ami rögtön meg is mutatkozott, mikor kibontottam a csomagot. Először is, nincs rajta bekapcsoló gomb! Mintha nem is számítógép lenne, hanem egy hűtőszekrény, vagy vasaló. Szinte nincsenek is rajta csatlakozók, csak kivezetések az alaplapról.

Azt sem tudtam, hogy a gép kétféle billentyűzet kiosztással került forgalomba. Egy némettel és egy angollal. Természetesen németet vettem, német hibaüzenetekkel. (Később tanultam meg átállítani angolra.) Azt sem értettem, mit ír ki a gép. Ha már a billentyűzetnél tartunk, az valami katasztrófa. Egyszer régen vettem egy összehajtható gumi billentyűzetet, mondván az milyen menő, de használni valami borzalmas volt. Az Enterprise billentyűzete még ennél is rosszabb. Egyáltalán nem kényelmes, szenvedés használni. A 10 print "hello", 20 goto 10 program megírása itt volt a leglassabb.

Először be sem tudtam kapcsolni. Kaptam hozzá egy SCART csatlakozót, amit ha beköttöttem, és még a magnót is rákapcsoltam, nem volt képe. Ha nem kötöttem be a magnót, akkor halványan felderengett a gép képe. Kétszázötvenhat szín? Egy színt láttam, 5 árnyalatban.

Végül maradt az RF csatlakozó, mert úgy bejöttek a színek. A kazettáról a cikk megjenéséig még nem sikerült betölteni semmit, mert a betöltésnél a hangerő szabályozó állása nem mindegy milyen szinten áll. Ezt a képernyő tetején egy szines csíknak kellene jeleznie, ha a hangerő megfelelő.

Ennyit a negatívumokról. Lássuk, melyek az értékek. Először is, a BASIC értelmező egy kis dobozban, külön kapott helyet a gép oldalában. Ez hallatlanul jó ötlet. C64-en nekem nagy fájdalmam volt, hogy közönséges BASIC-ből nem lehet elérni a grafikát. Volt ugye a Simon's Basic, ami orvosolta ezt a problémát, de ha azt is betöltöttük, újabb értékes memóriát vesztettünk. Enterprise alatt erről szó sincs. Az egyetlen probléma, hogy a gép ezen tulajdonságát nem használták ki annak idején. A modern kor felhasználói azok, akik ide terveztek egy SD kártya olvasót.

A hardver elég erős, hogy más Z80 számítógépet emuláljon. Tehát elméletileg a ZX Spectrum és Amstradt CPC demók is futhatnak rajta. Majd meglátjuk, ki fogom próbálni. A gép még most is szépnek tűnik a maga egyedi megjelenésével. Még a lányom is ki akarta próbálni, annyira tetszett neki.

enterprise.jpg

Meglepő, de kicsi és csendes közösség formálódott a gép köré. Nekik is van klubbjuk, szerveznek találkozókat, és jól elvannak. Ezt elég furcsa látni az Amigás közösség után, akik nagyon hangosak tudnak lenni, és napokon keresztül el tudnak vitatkozni azon, mi is az Amiga.

Az első benyomások nem túl pozitívak a részemről, remélem a későbbi kalandok érdekesebbek lesznek.

Szólj hozzá!

Címkék: enterprise

BitLocker-es pendrive olvasása Linux alatt

2020.03.22. 22:29 Travis.CG

Időről-időre megpróbálnak kitolni a Linuxosokkal, de azok elég jól veszik az akadályokat, noha a megoldás során néha-néha csúnyább szavak is előfordulnak szókincsünkben.

Az egyik ilyen akkor történet, amikor szekvenálási eredményeket kaptunk BitLockerrel titkosított pendrive-on. A tároló sertés metagenomikai mintákat tartalmazott. Hiába, már a disznók belében élő baktériumok személyiségi jogaira is tekintettel kell lennünk.

Mindegy, a lényeg, hogy nekem el kellett olvasni a tartalmát. Az egyetlen elérhető program a dislocker. A fordítása fájdalommentes, a szükséges dependendciák szinte minden repoban megvannak. A használata koránt sem triviális. A dokumentáció szerint csak egy bejegyzés kell a /etc/fstab fájlba, és már kész is.

Ne higgyünk neki.

Mivel az eszköz titkosított, az automount megdöglik rajta. Az lsblk parancs segítségével kell kideríteni, USB tárolónk melyik eszközleírót kapta. Ha megtudtuk, kezdődhet a munka érdemi része.

Először is dekódolni kell a partíció tartalmát:

sudo dislocker -r -V /dev/sdc1 -u pendrive

Itt meg kell adnunk a dekódoláshoz szükséges jelszót. Ha a pendrive egy könyvtár, akkor lesz benne egy dislocker-file nevezetű állomány. Ez a teljes partíciót tartalmazza egyetlen fájlban. Használatához ezt még egyszer csatolni kell, pont úgy, ahogy egy ISO képfájllal is teszi az ember.

sudo mount -o loop,ro pendrive/dislocker-file pendrive2

Na, ekkor érhetjük el a fájlokat a pendrive2 könyvtárban. Erre azért van szükség, mert a dislocker csak dekódol, a partíciókat magukat nem kezeli.

Szólj hozzá!

Címkék: rendszergazda

A publikációk ábráiról

2020.03.18. 22:15 Travis.CG

A kutatók néha olyanok, mint a gyerekek. Nagyon akarnak egy ábrát. Minden nap rágják a fülem: az nagyon jó ábra, olyan kell az én cikkembe is! Elkészítem nekik, mire a következő hónapban már egy másik ábrára fáj a foguk, amit megláttak kedvenc újságjuk hasábjain.

Az ábráknak az a feladatuk, hogy információt közöljenek. De egyes ábrák nem adnak semmi új információt, csak szokatlan köntösben mutatnak valamit, amit egy oszlop diagramm is képes bemutatni, de ez elég egyes kutatóknak, hogy zombi üzemmódba kapcsoljanak. Szemük üvegessé válik, réveteg mozgással kezdenek közlekedni, és nem azt kántálják: "agy, agy", hanem "ábra, ábra". Ebből az ábra éhségből csak a filmekből  ismert módon gyógyíthatóak ki.

Az első ilyen ábra a floral venn-diagram. Mikor meghallottam, nem erre gondoltam. A venn diagrammnak az a lényege, hogy lássuk, az egyes kategóriákban mennyi átfedés van. Pont ez az, amit a floral venn-diagramm nem mutat meg. Megkérdezték, tudnék-e ilyet készíteni. Azt válaszoltam, ilyet mindenki tud készíteni, még a hat éves lányom is. Kell rajzolni egy virágot, a szirmaiba meg számokat kell rakni. Szerintem ehhez nem kell dedikált R csomag, csak egy Paint.

A második eset több fordulós volt, mint egy mérkőzés. Először egy PowerPoint prezentációt kaptam, amiben megláttak egy szép interakciós hálózatot. Olyat akartak, függetlenül attól a ténytől, hogy nem volt egyetlen iterakciós adatuk sem. Megsajnáltam őket, és mondtam, hogy a GO adataikból lehet hasonlót csinálni, de az biztosan nem ilyen lesz, mivel a GO egy irányított aciklikus gráf. Természetesen nem ezekkel a szavakkal mondtam el, mert ettől kiolvadt volna az agyuk. Ennek ellenére láthatóan csalódottak volta, amikor meglátták a végeredményt.

Ezután jó ideig nem kellett semmit csinálni nekik, de ők tovább olvasták a cikkeket, és csak idő kérdése volt, hogy valami kiváltja náluk a nyálfolyást. Következő kiszemeltjük a toxpi ábra volt, amit egyetlen programmal, a ToxPi-al készíthetünk el. Bevallom, nekem többszöri nekifutásra sem sikerült kitalálni, mit is csinál ez a program. Valami adatokat be kell nekik adni, amitől kiszámolja a ToxPi pontszámot. Kaptam egy cikket is, amibe a normalizált expressziós adatokat felhasználva elkészítették ezeket a szörnyű kör diagrammokat.

A cikk alapján ugyan azzal a módszerrel elkészítettem az ábrákat az ő adataikra is, de az eredménynek semmi értelme nem volt. Főleg azért, mert nem lehetett tudni, mit jelent az eredményül kapott pontszám. A levélváltások során teljesen egyértelmű volt, hogy a partnereknek fogalmuk sem volt, mit várnak az ábrától, de látták, hogy van ilyen, akkor nekik is kell.

Egy korábbi munkahelyemen sem volt elég ha R-ben elkészítettem az ábrákat. Azt a kritikát kaptam, hogy az "összes kínai ilyen ábrát produkál a cikkeiben". Nem értettem, ez miért baj. Nem sztárokról írunk pletykákat, hanem tudományos eredményt mutatunk be. Ennek ellenére olyan erős volt a nyomás az egyedi ábrák elkészítésére, hogy egyik munkatársam soha nem olvasta el a rendszeresen kézhez kapott folyóiratokat, csupán ebéd előtt átlapozta, hogy van-e benne "érdekes ábra". Ha nem volt, bele sem olvasott.

Szerintem elsődlegesen jó cikket kell írni. Jó cikk alatt azt értem, hogy a módszerekbe ne lehessen belekötni, az alkalmazott statisztika kifogástalan legyen. Ha ez mind megvan, akkor ezt megkoronázhatjuk egy olyan ábrával, ami szemléletesen bemutatja az eredményeket. Ha csak azért akarunk szép ábrákat, hogy a bírálókat hipnotikus állapotba hozzuk, hogy könnyebben elfogadják a cikket, akkor érdemes lenne új karrier lehetőség után néznünk. Mondjuk egy sztármagazinnál.

Szólj hozzá!

Címkék: filozofálás

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