Az élet kódjai

A katasztrófa-filmekben azt szeretem, hogy bármilyen nagy problémával is találkoznak az emberek, végül a leleményesség, ész, bátorság segítségével úrrá lesznek a problémákon. Természetesen mindig van egy szereplő, aki az emberi kicsinyességet és butaságot testesíti meg (valami miatt többnyire polgármester a foglalkozása), de ő létszámban alul marad és a végén valami szörnyű halált hal, mintha még a katasztrófa is büntetni akarná ostobaságáért.

Egy ideje nem nézek katasztrófa-filmeket, hiszen van saját bejáratú katasztrófánk. De ebben a történetben valami miatt a butaság van túlsúlyban. Nem kell messze menni, elég csak a saját környezetemet vizsgálni. Álljon itt elrettentő példaként, és ez alapján talán mások felismerik a saját környezetükben azt, amin érdemes változtatni.

Először is, az anyósom nagyon szerette volna, ha elmennénk hozzájuk Húsvétra. Ezt eleve egy nagyon rossz ötletnek tartottam, mondtam a feleségemnek, hogy ne menjünk. Az volt a válasz, hogy "elvárják". Az én ostobaságom az volt ebben a történetben, hogy nem álltam eléggé a sarkamra, hagytam elfajulni a dolgokat.

Annyit sikerült elérnem, hogy ne tömegközlekedéssel menjünk. Mivel nekünk nincs autónk, apósom jött el értünk, ami elég nagy tortúra volt neki, hiszen két és fél óra alatt ért el hozzánk. Indulás után arról beszélgettünk, milyen súlyos a koronavírus járvány és emberek mennyire nem veszik komolyan. Az ő ismerősei között is vannak, akik szerint az oltás hülyeség, majd beszélt egy másikról is, aki azért nem ment el az oltás időpontjára, mert pont akkor hozták neki a fát.

Aztán szóba hozta, hogy a sógornőm betegeskedik, de ő akkor is ágynak esik, ha "letörik a körme". Nem most kezdte a betegeskedést, hanem már egy hete tart, de erről az elég fontos dologról valahogy nem beszéltek nekünk, pedig a látogatásaink előtt exponenciálisan emelkedik a telefonálások sűrűsége a feleségem és anyósom között.

Ekkor már kezdett felmenni bennem a pumpa, de azzal próbáltak megnyugtatni, hogy vettek a gyógyszertárban tesztet, ami negatív volt, és ez egy olyan erejű bizonyíték, hogy egy három tagú család egészségét fel lehet tenni rá.

Az út felénél jártunk, amikor kaptuk a telefont, hogy megjött a PCR teszt eredménye, ami pozitív lett. Itt már a feleségem is, én is mondtuk, hogy forduljunk vissza. Anyósomat felhívták, aki elég szomorú volt, mert már "feltettem főni a zöldborsót". Engem ekkor személy szerint a zöldborsó hőkezelése foglalkoztatott a legkevésbé. Mivel ott volt nála a négy éves keresztlányunk is, őt is a telefonhoz adta, aki sírva kérdezte, miért nem jövünk, amikor ő annyira várt bennünket.

Szegénynek csak annyit mondtak, hogy "anya beteg". Biztos vagyok benne, hogy nem értette, hogy anya betegsége miként függ össze a mi utazásunkkal, és abba is, hogy sokkal jobb magyarázat lett volna az, hogy mi nem akarjuk elkapni ezt a nyomorult betegséget.

Szépen visszamentünk. Utána még természetesen anyósom felhívott minket, és előadta, hogy a pozitív teszt ellenére sógornőm biztosan nem lehet kovidos, mert nem lázas. Ezt kérem egy volt egészségügyi dolgozó szájából lehetett hallani. Én elhiszem, hogy egy nagyszűlőnek hiányzik, ha Húsvétkor nem örjöngenek körülötte az unokák, de szerintem ennél fontosabb dolgok is vannak.

Ha már katasztrófa van, akkor viselkedjünk úgy, mint a főszereplők, ne úgy, mint a polgármester.

Néha a legváratlanabb helyről kapok tippeket. Még a pandémiás idők előtt a konditeremben kérdezték tőlem, milyen programmal szoktam videókat szerkeszteni. Az én régi módi módszereim számítógépet igényelnek, de kiderült, hogy elég tekintélyes számú megoldás létezik mobiltelefonra is.

Beszélgetőpartneremnek természetesen ez feküdt, mert úgyis a telefonnal készíti a videókat, miért másoljon mindent át egy másik eszközre? A telefonnál a kijelző mérete az, ami megnehezíti egy klippben való pozícionálást. Ha ezt a lépést valahogy ki lehetne váltani, akkor semmi nem gátolná meg, hogy a kütyün szerkesszük a videókat.

A Magisto ezt a lépést egy tanuló algoritmusra bízza. Mikor először megláttam, mire képes, nagyon impozánsnak találtam az eredményt. Látványos volt, dinamikus, miközben a belefektetett emberi munka minimális volt. Elhatároztam, hogy kipróbálom, nekem is beválik-e.

A munka érdemi része természetesen nem az eszközön történik, hanem a felhőben, ezért egy jó internetes kapcsolat elengedhetetlen. Arra gondoltam, letesztelem, hogy mire képes a program, ha például a 2019-es Functionra beadott videóm alapanyagával etetem meg. Legyen ez amolyan ember vs gép összecsapás. Nézzük meg, félni kell-e adtól, hogy a wild compókat elárasztják az olcsó, AI szerkesztette videók.

Általában én úgy dolgozom, hogy több, hosszabb videót készítek, majd az editálás során kivágom az érdekesebb részleteket és elkezdem a zene ütemére összepakolni őket. Közben többször is megnézem a klippeket, hogy inspirációt szerezzek, melyik részhez melyik klipp lenne jó. Nyilván nem ez a legjobb megoldás, de nekem nem is kell a legjobbnak lenni.

Az első probléma az volt, hogy a Magisto csak legfeljebb 10 másodperces klippeket engedett feltölteni, mert ezzel tud csak dolgozni. Kénytelen voltam kivágni neki megfelelő hosszúságú részeket a nyers videókból. Ezekből sem lehetett feltölteni akármennyit, mert én csak a próba verziót használtam. Ha ezt nézzük, akkor a rendszer nálam meg is bukott, hiszen egy 3-4 perces videót nem tud készíteni 1-2 órás alapanyagból. De ha már itt tartunk, nézzük meg, mennyire tudja megkönnyíteni a munkát.

Feltöltöttem az általam kivágott részeket, hozzáadtam a zenét, majd néhány kérdésre kellett válaszolni, hogy milyen legyen a videó stílusa. Ezek igazából csak különböző filtereknek tűntek számomra, tehát senki ne gondolja, hogy kattintok a Michael Bay opcióra, és rögtön jön a forgó kamera.

Az én esetemben nem sok mindent csinált a program (vagy fogalmazzunk úgy, nem sok látványos dolgot), szinte csak egymás mellé pakolta a klippeket és szénné effektezte. Egyetlen kockát sem hagyott érintetlenül, mindenre adott valamit, még abban az esetben is, ha direkt visszafogtam az alkalmazandó effektek számát a beállításokban.

Túl sokat sajnos nem lehet játszani az ingyenes kipróbálási lehetőséggel. A második-harmadik próbálkozásra már csak SD felbontású videót eredményez. Rövid játszadozásom tehát egyetlen értelmes videót sem eredményezett. Ezért elhatároztam, megnézem, mások milyen eredményre jutottak a program segítségével. Egy idő után már kezdtem felfedezni némi mintázatot, feltűntek az így készült videókkal a közös elemek. Vagyis úgy tűnik, kreatív munkára nem alkalmas. Amit készít, egyfajta tömegtermék.

Ezt erősíti meg a cég weboldalán látható különböző sablonok, valamint mely területeknek nyújtanak támogatást. A tucat munka elsőre derogáló kifejezésnek tűnhet, bár vannak bizonyos előnyei is. Például szerintem a legtöbb mobiltelefonos videó elég pocsékul néz ki. Remeg a kép, nincs elég fény, elmozdul a fókusz, stb. A megfelelő pillanatot is nehéz elkapni. Ha évekkel később megnézzük a felvételt, gyakran már nem is értjük, miért vettük fel valaki hisztérikus kacagását. Ha pedig értjük, akkor az válik rejtéllyé, miért találtuk ezt régen viccesnek. Ráadásul a telefonos videózás olcsó, ezért gondolkodás nélkül levideózunk mindent, nem mérlegelve azt, hogy van-e értelme.

Ezekből a nagyszámú, többnyire selejtes videóból a Magisto készít egy vállalható eredményt, amivel lehet villogni a haverok előtt. Jó eséllyel képes kiválasztani a megfelelő pillanatot, a hibákat pedig digitális sminkkel szépen elfedi, ha pedig a havernak is hasonló a videója, az nem zavar senkit, mert nincs verseny.

Azoknak, akiknek a munkájukhoz kell videó tartalmat készíteni (például egy ingatlan ügynöknek), azoknál szintén előny, ha a minden lakást hasonló módon mutatnak be. Ráadásul nem kell alkalmazni egy embert, aki a 200. videó után elátkozza azt is, aki feltalálta a videókamerát, mert már annyira unja, hogy mindent ugyan úgy kell megcsinálni. Nekik segítség lehet egy ilyen program. Ráadásul ők készítenek annyi videót, hogy megérje előfizetni a szolgáltatásra.

Mert a másik rékfenéje a Magistonak, hogy előfizetéses rendszerben működik. Egy magánembernek szerintem nem éri meg. Hiszen egy évben van egy nyaralás (esetleg kettő, ha télen síelni is elmennek), egy-két születésnap, karácsony, és néhány emlékezetes esemény. A többi időszakban nem csinálnak videókat, de a pénzt akkor is be kell fizetni.

Beszélgettünk is a konditeremben, hogy talán érdemes lenne többünknek összeállni egy előfizetésre, mert külön-külön nem videózunk annyit, hogy megérje előfizetni. Végül nem mentem bele, mert nekem szükségem lenne, hogy letötlhessem a videót, ráadásul én a kreatív alkotás felől közelítem meg a videóvágást, még ha ez nem is látszik meg a végeredményen.

Annyit viszont én is tanultam ettől a mesterséges intelligenciától, hogy nem kell félni egy kis effektezéstől. Ha például van két nagyon hasonló beállítás, akkor egy effekt alkalmazásával el lehet érni, hogy ne tűnjön annyira repetitívnek. Ezt alkalmaztam is a tavalyi Revision-ön, bár így is csak 11. lettem.

Mivel nem sikerült megoldást találnom a GUS kártyás gép problémáira, ezért a munkahelyi nagy szanálás idején mentettem egy Pentium 1-es gépet. Beleraktam a a hangkártyát, a CD olvasót DVD-re cseréltem, és ment minden, mint a karikacsapás. A DVD olvasó is működött, nem fagyott le, mint az előző gépnél. Egyetlen hátránya, hogy soros egérrel üzemel, ezért az USB, PS2 egerek mellett már egy soros egér is van az asztalomon. Ez legyen a legnagyobb probléma.

Megpróbáltam két egérre szűkíteni a beviteli eszközök számát, de nem sikerült. Először egy átalakítóval próbálkoztam, de rá kellett jönnöm, hogy a lézeres egeret átalakítóval sem lehet rácsatlakoztatni a gépre, mert nem ad le elég feszültséget, hogy az elektronika üzemeljen. Mindenképp egy golyós egérre van szükség. Még szerencse, hogy nálam ilyen is van.

A DIN-es átalakító segítségével a PS2-es billentyűzet gond nélkül üzemelt, ezért abból nem kellett egy harmadik az asztalra. Oké, akkor elméletileg meg tudom nézni az összes GUS-os demót. És gyakorlatilag?

Először is le kellene tölteni az összeset. A Pouet.net oldalán ott vannak HTML-be ágyazva az összes információ. Egy közönséges wget-es szkripttel letöltöttem az összes oldalt, amiben felsorolták a GUS tartalmú alkotásokat. Ez könnyű volt, csak egy GET-es paramétert kellett változtatni az URL-ben. Mivel ez csak egy összesítő oldal, szükség van minden egyes alkotás adatlapjára, ahol megvannak a közvetlen linkek. Ebből ki kell nyerni a közvetlen linket, és kész.

Mivel a munkahelyi tapasztalatokból tudom, hogy rengeteg anomália fog fellépni a letöltés során, ezért először csak egy táblázatot készítettem, ahol az alkotás neve, pouet azonosítója és a letöltés linkje szerepel.

Az anomáliák persze jöttek is. Mivel ezek DOS-os programok, a 8+3 fájl név limit miatt több alkotásnak is ugyan az volt a fájlneve. Voltak döglött linkek, ahonnan már semmit nem lehetett letölteni, szerencsére ezekből kevés akadt. Egyes esetekben pedig kézzel kellett finomhangolni a letöltést, mert az elérési út nem teljesen az volt, ami a Pouet.net-en látható.

Végül sikerült! Összesen 1211 produkciót sikerült letölteni. Kényelmesen elfértek egy DVD-n.

Sajnos elsőre rosszul írtam ki, mert a Windows beépített DVD író alkalmazását használtam, ami minden igyekezetem ellenére is UDF-ben írta ki az adatokat. Természetesen pont ez az a formátum, amit FreeDOS alatt nem tudok olvasni. Másodszorra már ISO-ként írtam ki, mire mindent gond nélkül tudtam használni a GUS-os géppel.

Ez a szám elég tekintélyes. Ha csak tízet nézek meg naponta, akkor is négy hónap, mire a végére érek. Kinek van szüksége ezek után Netflixre?

Az ember diploid élőlény, ami azt jelenti, hogy a teljes kromoszóma készletéből kettő van. Egy anyai és egy apai eredetű. Ha csak a legegyszerűbb DNS változásokat, a nukleotid variációkat nézzük, akkor ez azt jelenti, hogy ha megnézzük egy egyén SNP-it, akkor azt jó eséllyel megtalálhatjuk legalább egy szülőben is (feltéve, hogy eltekintünk a szekvenálási hibáktól, spontán mutációktól, nukleotid modifikációktól és még egy csomó olyan dologtól, ami csak azért van, hogy összezavarja az ép ésszel megérthető modelljeinket).

Jogos igény, hogy a vizsgálatok során megtalált mutációkat hozzá tudjuk rendelni vagy az anyai vagy az apai kromoszóma készlethez.

Amennyiben nem használtunk speciális könyvtár előkészítési módszereket, úgy bioinformatikai eszközökkel kell megbírkózni a problémával. Ahogy azt már megszokhattuk, itt jönnek a gondok.

Amikor ugyanis egy biológus haplotípusról beszél, akkor az alatt a klasszikus anyai és apai kromoszóma felosztást érti. Ez pedig alapesetben csak és kizárólag bioinformatikai eszközökkel megállapíthatatlan.

Amit egy bioinformatikus meg tud csinálni, az a variációk haplotípus csoportokba rendezése. Mit jelent ez? Azt nem tudom megmondani, hogy apai vagy anyai eredetű-e egy mutáció, de azt mondhatom, hogy az adott mutáció az előtte-mögötte lévő mutációk közül mennyivel van azonos kromoszómán. Ha pedig véget ér egy haplotípus csoport, és kezdődik egy másik, akkor azt célszerű teljesen független egységnek kezelni.

A VCF fájlban, ha egy mutációról egy program meg tudta állapítani, hogy egy adott haplotípus csoportban van, akkor egy "pipe" jellel választja el a genotípust a perjel helyett. Ezt a VCF fájl 10. oszlopától kezdődően láthatjuk, attól függően, hogy mennyi mintát tartalmaz a fájl.

Miként határozható meg, hogy két mutáció egy haplotípus csoportban van-e? A legegyszerűbb módszer, amit akár mi magunk is elvégezhetünk egy IGV segítségével, ha megnézzük, hogy a két mutáció egy readen van-e. Ez a módszer természetesen csak akkor működik, ha a mutációk távolsága kisebb, mint a read hossza, és a mutációk heterozigóták. (Hiszen a homozigóta mutációk mindkét kromoszómán megvannak.) Ha azt látjuk, hogy az egyik mutáció csak a readek felében fordul elő, míg a másik mutáció a readek másik felében fordul elő, akkor különböző kromoszómán vannak. Ha konzekvensen ugyan azon a readen vannak, akkor egy kromoszómán vannak.

Ennek a módszernek a kiterjesztése, ha egy de-novo összeszerelést végzünk, amivel szinte meghosszabbítjuk a readjeinket. Ezt csinálja a GATK HaplotypeCaller modulja.

A módszer a hosszú readek korában reneszánszát éli. A humán X kromoszóma teljes összeszerelése közben azt vették észre a kutatók, hogy a mostani technológiával mindig találni annyi heterozigóta SNP, indelt vagy struktúrális variációt, hogy akár még a centromereken is átívelő haplotípus csoportokat tudtak felépíteni.

A másik módszer, hogy megszekvenáljuk a szülőket. Ezt csinálja például a Beagle program is, de csak a 3-as verziója. Mivel a variációk nagy részét örököljük, nem nehéz megmondani, hogy mi az eredetük. A problémát itt a spontán mutációk okozzák, amelyek nem találhatóak meg egyik szülőben sem.

További lehetőség, amennyiben rendelkezünk genetikai térképpel, hogy meghatározzuk, milyen messze vagyunk a rekombinációs pontoktól. Minél közelebb vagyunk, annál nagyobb az esélye, hogy a haplotípus csoportunk széléhez tartunk.

Mielőtt tovább mennénk, vizsgáljunk meg még egy lehetőséget. Amennyiben nincs lehetőségünk a szülők szekvenálására, de van egy nagyobb genotípizált populációnk (modell organizmusok előnyben, ugyebár) akkor annak segítségével is megállapítható, hogy hol van nagyobb eséllyel rekombináció. Ez a lehetőség a Beagle 4-es verziójától felfelé érhető el. (Miközben az öröklésen alapuló módszert szépen kivették a program funkciói közül.)

Ami a fenti módszerekben közös, hogy végül egy rejtett Markov lánc segítségével próbálják meg meghatározni a haplotípus csoportok határait. Ezt csinálja a HaplotypeCaller, a Beagle a régi és az új verzióiban egyaránt. Itt emlékezzünk vissza, mit is tapasztaltunk, amikor játszottunk a saját rejtett Markov láncunkkal. Nevezetesen, hogy az állapot változások kezdete és vége nem mindig esik egybe a tényleges rejtett állapotok átmeneteivel.

Ezt akkor vettem észre, amikor egy trio adat elemzése közben fázisolni akartam. Lefuttattam a Beagle 3-t, Beagle 5-öt, miközben a VCF a HaplotypeCallerrel készült. A három eredmény elég eltérő volt ahhoz, hogy elkezdjek a dolgok mélyére ásni. Arról nem is beszélve, hogy a rejtett Markov láncok sztochasztikus modellek, tehát az eredmény futásról futásra változhat. Ezért gondolom, hogy a haplotípus meghatározás egy átverés. Hiszen nem azt mondja meg, amit egy biológus elvár, és azt is rosszul. Nem annyira rosszul, mint egy exom alapú CNV, de elég rosszul, hogy az eredményeket kételkedve fogadjam.

A helyzet a hosszú read szekvenálásokkal javulni fog, sőt, most is vannak olyan könyvtár előkészítési eljárások (például a 10x Chromium), amelyek segítségével pontosabban határozhatjuk meg a haplotípusokat. Ha mégis olcsóbban akarjuk megúszni, akkor a referencia panel alapú megoldást válasszuk, mert jelenleg az a legpontosabb. Ha olyan fajjal dolgozunk, ahol nincs referencia panel, akkor próbáljuk megszekvenálni a szülőket is, de ha ez sem megoldható, akkor ne számítsunk semmi jóra.

- Bocsánat, főfelügyelő úr, de a segítségét kell kérnem - mondta félve a kalaúz, mikor belépett a szűk kis vonatfülkébe.

A férfi letette az újságot, amit éppen olvasott és a kalaúzra pillantott.

- Ennek köze van ahhoz, hogy a vonat nem megy? - kérdezte Poirot.

- Azt hiszem, igen. Tudja, lefagyott a Számítógép, és Ön, mint az összeomlások szaktekintélye, talán tud segíteni.

- Roppant sajnálatos, amit mond, de most épp nyaralok. Ki a területi illetékes?

- Már felvettük a kapcsolatot a hatóságokkal, de amíg ideérnek, kihülhetnek a nyomok. A tetteseknek itt kell lenniük. Mint Ön is tudja, a legközelebbi állomás is több száz kilóméterre van innen. Úgy is mondhatnám a semmi közepén vagyunk.

- Ez esetben a tettes sem tud elmenekülni. Nincs más dolgunk, mint megvárni, hogy a hatóságok ideérjenek - dőlt hátra Poirot.

- Van még egy dolog. Ha megvárjuk, hogy megérkezzenek a nyomozók, az legalább öt óra. Megkezdik a nyomozást, további órák fognak eltelni.

- Értem, de az illetékesek biztosan nem fognak örülni neki, hogy belekontárkodom az ügyükbe. Mint rendőrnek, nekem is kellemetlen, ha mások akarják elvégezni a rám szabott teendőke.

A kalaúz roppant feszélyezetté vált. Szemmel láthatóan gyötrődött, hogyan vegye rá a híres főfelügyelőt, hogy szegje meg a bűnüldözők íratlan szabályát. Poirot látta ezt.

- Talán annyit mégis megtehetek, hogy előkészítem a terepet a kollégáknak.

A kalaúz láthatóan megkönnyebbült. Egy biccentéssel köszönte meg, majd így folytatta:

- Kérem főfelügyelő úr, erre jöjjön. Az utasok már várják.

Egy kis kupéban foglalt helyet a nyolc ember. Poirot alaposan szemügyre vette őket.

- Üdvözlöm Önöket. A nevem Poirot. Egy sajnálatos összeomlás miatt vagyunk itt. Önök mindegyike hardver komponens, akik jelen voltak. A felelős önök között van.

- Tipikus - szólalt meg egy díszes ruhába öltözött hölgy. Lila ruhája és millió fodros kalapja volt. - Amint történik egy összeomlás, azonnal a hardverekre esik a gyanú. Miért nem nézi meg a másik kocsit, ahol a szoftver komponensek vannak? A bárban hallottam, hogy a Windows például hónapok óta nincs frissítve.

- Kit tisztelhetek kegyedben? - kérdezte Poirot.

- Ms. Memória vagyok. Nem kevesebb, mint 32 GB. Négy modulban helyezkedem el és évek óta gond nélkül látom el a feladatomat.

- Igaz, de elég csak egy modul rossz működése és máris kimerevedik a kép. Mivel Ön 32 GB, ami elég nagy, a hiba nem lesz perzisztens, csak ha épp a rossz modul kerül használatba.

Ms. Memória dacosan felhúzta az orrát, és elfordította a fejét.

- A hölgyne ettől függetlenül igaza van. Miért nem az operációs rendszereket kérdezi ki? - vetette közbe egy magas, fehér öltönyös úr. Hanyagul keresztbe tette a lábát és épp kávét szürcsölt.

- Mert több fagyás is történt. Windows és Linux alatt egyaránt. Ez pedig a hardver hibára utal.

Döbbent csend követte a bejelentést. Az emberek zavartan egymásra néztek.

- Bocsátnat, a nevem Tápegység. Nekünk a kalaúz azt mondta, hogy csak egy fagyás történt - mondta egy kopott kabátot viselő úr. Kicsit kilógott az úri társaságból. A többiek látszólag tudomást sem vettek róla.

- Mert a második fagyásról a kalaúz nem tud. Ő csak a Windowst ismeri, ezért a Linux alatti fagyás elkerülte a figyelmét. Észrevettem, amikor bekövetkezett, de nem szóltam, mert nem voltam biztos, hogy Windows alatt is meg fog-e ismétlődni. Ráadásul nyaralok, hivatalosan nem kezdeményezhetek nyomozást.

- Most mégis itt van - jegyezte meg a fehér öltönyös úr.

- Csak addig, amíg a hivatalos szervek meg nem érkeznek. Az érkezésükig órák is eltelhetnek, a vizsgálat lefolytatása szintén hosszadalmas lehet, ha addig közelebb jutunk a megoldáshoz, hamarabb elmehetünk. Közös érdekünk, hogy ne vesztegeljünk itt sokáig.

- Mi történik, ha nem működünk együtt? - kérdezte egy merev tartású, katonai egyenruhát viselő férfi. - Hiszen maga mondta, hogy csak nyaral. Csak annyi joga van, mint bármelyikünknek itt a kocsiban.

- Úgy látom, Ön ezredesi rangban szolgál a seregben.

- Jól látja. Processzor ezredes vagyok, a 8350FX-es zászlóaljban. Nyolc mag tartozik a parancsnokságom alá.

- Az jó sok mag. Elég nagy eséllyel okozhat fagyást.

- Ha tényleg olyan szaktekintély lenne, mint ahogy hírlik Önről, akkor tudná, hogy hibás CPU esetén egyáltalán nem indul el a számítógép.

- És mi a helyzet a túlmelegedéssel? Alaphelyzetben semmi rendellenes nem látszik, de elindul két-három program, és megnövekszik a fogyasztás. Megemelkedik a hőmérséklet, majd minden lefagy.

- Az én parancsnokságom alatt ez elképzelhetetlen. Legfeljebb, ha az a léhűtő Ventillátor nem végzi a dolgát.

Minden szem egy flegma fiatal emberre szegeződött. Drága ruháit lezserül viselte, egyik-másik darab még gyűrött is volt, de Ventillátort ez nem zavarta. Haja is rendezetlen volt.

- Nem értem ezt a felhajtást - mondta egy fintor kíséretében. - A fordulatszámomat, Processzor kapitány...

- ...ezredes... - sziszegte a fogai közül a katona.

- ...bármikor megmondja az Alaplap. Tőle kell kérdezni ezeket.

- Gondolom, Ön lesz Alaplap - fordult Poirot a fehér öltönyös férfihoz, aki meglepetten nézett vissza.

- Honnan...

- Egyszerű. Az Alaplapnak mindenkivel kapcsolatban kell állnia. A testbeszéde elárulta, hogy Ön központi személy ebben a helyzetben.

- No, igen, az én szakmámban a kapcsolat jelent mindent - jegyezte meg nem kis önelégültséggel.

- Egy kapcsolat lehet jó, és rossz is. Nem kerülte el a figyelmem, milyen szemeket mereszt Önre Ms. Memória. Processzor ezredes pedig látszólag ellenséges Önnel.

- Ez egy régi vita közöttünk. Az ezredes felsőbbrendűnek tartja magát, mert minden számítást ő végez. Szerintem pedig fontosabb, hogy minden komponens zökkenőmentesen együttműködjön. Az adatnak el kell jutnia egyik helyről a másikra, nem elég kiszámolni azokat.

Az ezredes horkantott egyet, de nem szólt semmit.

- És mit mond Ön a fordulatszámról?

- Teljesen normális, a beállított értéken pörög.

- Észrevett bármilyen problémát a fagyás előtt? A szenzorai bizonyára érzékeltek valamit.

- Nem - majd kis szünet után hozzátette - De az újraindulás utána feltűnt valami.

- Micsoda?

- Processzor hiba.

Az emberek felhördültek. Az ezredes feje vörösödni kezdett, mint egy kitörni készülő vulkán.

- Az én részegységem minden pillanatban tökéletes munkát végez. Miközben maguk csak henyélnek, én akkor is dolgozom. Én gyűjtöm be az összes információt, és feldolgozom azokat a legjobb tudásom szerint! Míg Ms. Winchestene felpörög, én már milliónyi számítással végzek. Ventillátor mást sem csinál, csak szelet kavar. De ön - remegő ujjával Alaplapta mutatott - ahelyett, hogy eljuttatná az általam kiszámított eredményeket, csak megakasztja az egész folyamatot! Egymás ellen hangolja a részegységeket és meghamisítja a diagnosztikai jeleket.

- Én nem hamisítok meg semmit! - emelte fel a hangját Alaplap is. - Ha a POST alatt bármi történik, akkor jelzem. A fagyás után egyedül Önnel volt probléma.

- Kikérem magamnak! A maga szenzorai hibásak, hibás diagnózist állapított meg.

A kocsiba szó nélkül belépett egy hadiapród és az ezredeshez ment. Átvett tőle egy papírt és távozott.

- Mit adott át neki? - kérdezte Poirot.

- Lehet, hogy Önnek van ideje itt beszélgetni, de a munkának folynia kell tovább. Processzorként vannak bizonyos kötelezettségeim.

- Ahogyan nekem is. Ha megbocsátanak, akkor egy kicsit magukra hagyom önöket - mondta Poirot, majd válaszra sem várva az ajtó felé indult.

- Mégis hova megy? - csattant fel Ms. Memória.

- Megkérdezek valamit a kalaúztól - mondta titokzatosan a felügyelő, majd távozott.

- Most meg itt hagy minket - állapította meg Ms. Memória, inkább csak úgy, magának.

- Nem kell aggódnia drágám, hamar vége lesz ennek - vígasztalta Alaplap.

- Lehet, hogy azért próbálja rám hárítani a felelősséget, hogy leplezze a kisasszony bűnösségét - jegyezte meg Processzor.

Mielőtt bárki válaszolhatott volna, ismét megjelent Poirot.

- Kérem, kérem! Vádaskodással nem megyünk semmire. Azért vagyunk itt, hogy megoldjuk a problémát.

- A felügyelőnek igaza van - mondta Ms. Memória. - Én készen is állok, hogy bebizonyítsam ártatlanságomat. Csak futtatni kell a MemTest86-t, és utána látni fogják, hogy velem nincs semmi probléma.

- Hajlandó alávetni magát a tesztnek? - kérdezte Poirot. - Mint tudja, nem utasíthatom rá. Viszont ha megjönnek rendőrök, ők megtehetik.

- Természetesen alávetem magam. Nincs okom félni a teszttől, ártatlan vagyok.

A teszt nem volt rövid. Többször is meg kellett ismételni, hogy mind a négy modult leellenőrizzék. A végén Poirot szomorúan közölte:

- Önnek két memóriamodulja is hibás.

A hölgy nem szólt semmit. Méltósággal hallgatta, majd a szemében könnyek kezdtek gyűlni.

- Egészen biztos benne?

- Sajnos igen. Az random írás-olvasás teszt rendszeresen hibás értéket adott vissza. Többször is ellenőriztem.

- Akkor végig én voltam a hibás? Ez olyan hihetetlen. Amikor az ember összeomlást lát, mindig azt hiszi, az csak valaki más hibájából történhet. Soha nem gondoltam volna, hogy...

Befejezni már nem tudta. Hirtelen kialudtak a fények. Az utasok összerezzentek.

- Mi történt? - kérdezte pánikkal a hangjában Tápegység.

- Egy újabb fagyás, az történt - jegyezte meg csendben Poirot.

- Szóval Memória kisasszony újabb hibát produkált - jegyezte meg Processzor nem kis gúnnyal a hangjában.

- Nem. Ezuttal nem. A hibás modulokat eltávolítottuk a teszt végeztével. Memória kiasasszony már csak a jó modulokkal üzemel.

- Vagyis? - kérdezte Alaplap.

- Van még egy tettesünk. Mr. Alaplap, most mit mutat a POST teszt?

- Processzor hibát.

- Hogy nem sül le a képe még mindig engem pocskondiázni!

- Maga csak ne beszéljen. Folyton másra akarja kenni a problémát, holott már korábban is mondtam, hogy a maga tesztje nem sikerült. Minden részegység mellett van egy kis LED, és folyton maga melletti gyullad ki. Ezt mivel magyarázza?

Processzor ezredes nem válaszolt azonnal. Száját ragadozó mosolyra húzta.

- Maga azt sem vette észre, hogy Ms. Memóriával gondok vannak. Lehet, hogy Ms. Memória tényleg ártatlan, és az Ön foglalatai kontaktosak. Azt jelzi, hogy hiba van itt is, ott is. De valójában csak egyetlen hiba van - az ezredes közelebb lépett. - Maga.

- Nem - csak ennyit tudott mondani Alaplap, és hátrálni kezdett.

- De igen. Mondja csak meg neki, felügyelő úr. Egy kis áram ingadozás, korrodáció az érintkezőknél. De elég egy kis hibás kondenzátor, felpúposodott tetővel, és máris kész a baj.

- De..de...

- Az ezredesnek igaza lehet, de áram ingadozást más egységek is okozhatnak. Olyan egységek, amelyek egyébként is sok áramot vesznek fel - ezzel Poirot egy ikerpár felé fordult, akik eddig csendesen figyeltek. - Ha nem tévedek, a híres GPU ikrekhez van szerencsém.

- Igen - felelte a jobb oldali testvér. - SLI-be kötve - fejezte be a bal oldali.

- A teljes rendszer áramfelvételének a 2/3-a maguknak kell.

- A nagy teljesítményhez - kezdte a jobb oldali. - Nagy áram kell - mondta a bal oldali.

- A hőtermelésről nem is beszélve.

Az ikrek bólintottak. Lassú mozdulattal, akár csak a szinkron úszók.

- Úgy gondolja felügyelő úr, hogy az ikrek miatt megzavarodtak a szenzoraim? - kérdezte Alaplap.

- Csak arra akartam utalni, hogy a feszültség fontos tényező. Amíg kevés kell, addig észre sem vesszük, de ha megnövekedik a részegységek igénye, akkor akinek nem jut elég áram, nem működik megfelelően.

- Szerintem pedig az ezredes a ludas - mondta Alaplap, hogy visszaszerezzen némi önbecsülést, amiért allul maradt az előző szópárbajban.

- Figyelmeztetem, hogy... - kezdte vörösödő fejjel az ezredes.

- Az ezredes teljesen ártatlan - vágott közbe Poirot.

- Miből olyan biztos benne? - kérdezte Ms. Memória.

- Mert az ezredes parancsai nem jutottak ki ebből a szóbából. Mikor kimentem az apród távozása után, akkor azért mentem ki, hogy elintézzem, hogy a parancsai ne jussanak tovább. Egy másik katonatiszt látta el az ön feladatait ez idő alatt.

- Hogy mert engem lecserélni!? Ehhez nem volt joga.

- Ez igaz. Viszont szükséges lépés volt, hogy kiderüljön, Ön áll-e a hibák hátterében.

Alaplap láthatóan összetört a hallottak alapján.

- Akkor mégis csak én vagyok a hibás - mondta, majd egy fotelba huppant. Ms. Memória együttérzően mellé ült, és megsimogatta a kézfejét. - Az lenne a feladatom, hogy összehangoljak mindent, de képtelen vagyok rá. Ezek alapján csak is én lehetek, aki nem megfelelően működik.

- Kicsit túl szigorú magához - mondta Poirot. - Maga csak látott egy anomáliát, de nem látta az igazi okot.

- Ezt hogy érti?

- Amikor érzékelte, hogy Processzor felől nem jön információ, akkor azt hitte azért, mert Processzor működésében van valami probléma. De azért nem jött információ, mert nem jöhetett. Processzor ezredes ugyanis nem kapott áramot.

- Ezt nem értem. Összeomlás csak ritkán fordult elő. Az esetek nagy részében minden zökkenőmentesen működött. Hogyan lehetséges, hogy egyszer kap áramot, egyszer meg nem? Ennek semmi értelme.

- Igen, magam is szívesen venném, ha felvilágosítana - jegyezte meg az ezredes.

- Azonnal. Az áram ellátás ugyebár úgy néz ki, hogy megy egy 24 tűs ATX csatlakozó Alaplaphoz - a férfi bólintott. Van egy másik, illetve jelen konfigurációban két másik ár a GPU ikrekhez.

- Igen, igen, tudjuk mind. Kapnak Winchesterék, GPU, Alaplap. Minden részegység árammal megy, ezért van rajtuk csatlakozó. Legyen szíves a lényegre térni!

- A lényeg, hogy van még egy 12 Voltos csatlakozó, ami közvetlenül Önnek jár, bár Alaplap kapja. Ha ez az ág nem szállít elég áramot, akkor Alaplap úgy érzékeli, hogy Ön nem működik. Általában nincs is gond, de ha megnő a számítógép áramfogyasztása, akkor jelen esetben ez az ág nem ad le elég áramot. Tehát a tettes Tápegység!

Az említett férfi szeme elkerekedett. Hirtelen felugrott, és az ajtó felé kezdett futni. Az ezredes, azonnal utána vetette magát. Ms. Memória felsikoltott. Tápegység feltépte az ajtót, de visszahőkölt. A rendőrség emberei már ott voltak. Éppen be akartak kopogni. Tápegység kikapta az egyik rendőr övéből a pisztolyt.

- Álljanak meg. Maguk ketten - fordult az újonan jött rendőrök felé -  jöjjenek be, és álljanak a többiek mellé. Gratulálok felügyelő úr. Kicsit alábecsültem magát. Utoljára fogom megölni, hogy kifejezzem elismerésem.

- Maga álnok, képmutató disznó! - kiáltotta Processzor. - Tegye le azt a fegyvert, nem méltó rá, hogy viselje.

- Nem vagyok rá méltó? Mégis, hogy mondhat ilyet? Mindenki az én áramomat fogyasztja, mégis folyton panaszkodnak: "Nem lehetne még egy +12V csak nekem?" "Közös ágon vagyok a DVD olvasóval, ezt nem tűröm." Mégis lenéznek, tudomást sem vesznek rólam. Elegem van, hogy nem tekintenek igazi számítógép komponensnek. Processzor ezredes a megaherzekkel büszkélkedik. Alaplap az USB csatlakozók számával henceg. Fogadjunk, még a teljesítményemet sem ismerik. Ha pedig felmelegszem, annyi áramot adok másoknak, akkor meg a hűtőm zajával van bajuk.

- Ezért tette? Szeretne több figyelmet?

- Nem. Emlékeznek a tavalyi nagy túlmelegedésre? Amikor a hűtőpaszta annyira megszáradt, a házban 70 fok fölé ment a hőmérséklet.

Többen bólogattak.

- Akkor történt. Az egyik csatlakozóm pontosan Processzor fölött volt. Az összes meleg levegő ott keringett és megolvadt a csatlakozó műanyag vége. Azóta nem működök rendesen. Nem mertem szólni. Féltem, és összezavarodtam.

- Mutassa a sérült csatlakozót, kérem - mondta Poirot.

- Annyira sajnálom - mondta összetörten Tápegység. - Annyira sajnálom.

Leengedte a fegyvert, és hagyta, hogy a rendőrök elvezessék.

A rejtett Markov láncok nagyon hasonlóak a korábban bemutatott Markov láncokhoz, de van bennük egy csavar. Minden állapot bizonyos valószínűséggel emittál egy másik állapotot, amit látunk. Ezért az eredeti állapotot mi nem látjuk, tőlünk rejtve van, ezért hívják rejtett Markov láncoknak.

Például, ha azt vesszük, hogy egy (nagyon is leegyszerűsített) genomon egymást követik a fehérje kódoló, és nem kódoló szakaszok, akkor ez lehet egy rejtett állapot. Ezt mi nem látjuk (legalábbis a modell szerint, kísérleteket természetesen tervezhetünk a kimutatására). Amit látunk, az a DNS bázissorrend. Ha hétköznapi módon akarnék fogalmazni, a rejtett Markov lánc a közvetett bizonyítékok vizsgálatán alapul.

Gyakorati szempontból három algoritmust szoktak tárgyalni, ami a rejtett Markov láncok három alkalmazási módjával áll kapcsolatban. A Forward-Backward algoritmus, a Viterbi algoritmus és a Baum-Welch algoritmus.

Az első segítségével a modell paramétereit és megfigyelt állapotok kapcsolatát lehet számszerűsíteni, magyarul, mennyire jó a modellünk a megfigyelt adatokra. A Baum-Welch a látható állapotok alapján a modellünk paramétereit határozza meg.

A bioinformatikában általában a Viterbi algoritmust használják, mert ez mondja meg, hogy mi a legvalószínűbb rejtett állapot, ha ismerjük az emittált állapotokat. A példánknál maradva, hol vannak a kódoló/nem kódoló szakaszok, ha ismerjük a DNS bázissorrendjét.

A rejtett Markov láncokról rengeteget lehet olvasni a Wikipédián, én nem is akarom újra leírni azt. Amit viszont fontos megismerni, hogy mi a módszer gyengesége, mert a későbbi posztokban utalni fogok rá.

Ezért írtam egy kis programot, ami nem csinál mást, mint generál egy Markov láncot, és abból emittál bizonyos valószínűséggel egy másik állapotot. Ez most az időjárásos példa a Wikipédiából. Utána egy Viterbi algoritmussal visszafejti azt. Tehát egyszerre látjuk, miből indultunk ki, és mi lett a keresés eredménye.

Nyugodtam írjuk át a programban a valószínűségi értékeket, hogy lássuk, milyen hatással van az eredményekre. (Ha telepítve van a Go fordító, akkor a go build hmm.go paranccsal fordíthatjuk.)

Ha megnézünk egy tipikus kimenetet, akkor nem sok eltérést fogunk látni. Olyan esetekben lesz eltérés például, ha napos idő esetén is takarítanak. Mivel napos időben csak 0,1 a valószínűsége, hogy valaki takarít, ezért a Viterbi inkább az esős idő felé hajlik ilyen esetekben. Ez nem is meglepő, hiszen ez a legvalószínűbb állapot.

A másik fontos észrevétel, hogy az állapot átmeneteknél egyfajta "késés" van a valódi és a Viterbi által visszafejtett állapotok között. Igazából, ez sem meglepő, ha belegondolunk. Napos idő után nagy valószínűséggel megint napos lesz, esős után esős. Ha történik egy átmenet naposból esősbe (vagy vissza), akkor az algoritmus, ami csak az emittált állapotok alapján dolgozik, pár lépéssel később végzi el a váltást. (Persze ez is a valószínűségektől függ. Ha minden rejtett állapot csak egyfélét emittál, akkor ez a késés nem jelentkezik.)

És mi a helyzet a HMM profilokkal?

A bioinformatikában a rejtett Markov láncok alkalmazásának másik nagy területe a különböző profilok létrehozása, elsősorban fehérje alapon. Itt szó szerint rejtett állapotok vannak. Mit értek ez alatt? Az időjárásos példánál a rejtett állapot egy valódi entitás volt (maga az időjárás), csak nem szerezhettünk róla információt. A fehérje profiloknál viszont a rejtett állapot egy meg nem fogható jellemzője a fehérjének. Csupán egy absztakció, még akkor is, ha szoros kapcsolatban van az aminosav fehérjében betöltött pozíciójával. Amit mi látunk, tehát az emittált állapot, maga a fehérje aminosav sorrendje.

Most jön a trükk. Hogyan lesz ebből a megfoghatatlan valamiből profil? Hiszen nekünk ismernünk kell az emittált valószínűségeket. Úgy, hogy fogunk sok - valamilyen tulajdonság alapján hasonló - fehérjét és végzünk egy többszörös illesztést. Ha egy pozícóban csak glicin van, akkor az a rejtett állapot 100%-ban glicint emittál. Egy másik pozícióban azt látjuk, hogy néha alanin, néha fenilalanin van, akkor a modellben annak megfelelően állítjuk be a valószínűségeket, hogy a többszörö illesztésben hányszor fordul elő az adott aminosav.

Még a deléciók és inszerciók sem jelentenek problémát, hiszen azokat is felvehetjük rejtett állapotnak. Az inszerciók szintén emittálnak aminosavat, de a deléciók nem fognak semmit emittálni, a szerepük, hogy át tudjunk ugrani a következő állapotba.

Leegyszerűsítve, a többszörös illesztés oszlopai a rejtett állapotok, a sorok pedig az emittált állapotok. Itt az állapot átmeneteknek kisebb szerep jut. Képzeljünk el egy olyan többszörös illesztést, ahol nincsenek inszerciók, sem deléciók. Minden állapot 100%-ban átmegy a következő aminosavat emittáló állapotba. A profilban az igazi információt az emittálási valószínűségek fogják adni, mert abból derül ki, milyen aminosavat tartalmazhatnak az egyes pozíciók.

Talán ebből is látszik, hogy a rejtett Markov láncok rendkívül rugalmasan alkalmazhatóak. Nem véletlen, hogy szinte minden programozási nyelvhez adtak ki modulokat, amelyek segítségével rejtett Markoc láncokat kezelhetünk. Python alatt a hmmlearn csomagot érdemes használni, mert az közeli kapcsolatban van a sci-kit learn csomaggal. R alatt több lehetőségünk is van, az rHMM, a HMM és a depmixS4.

Habár előszeretettel hivatkoznak a DNS láncra, mint egy hosszú szalagra, ahol csak a nukleotidok sorrendje az egyedüli fontos ismertetőjegy, a valóságban a DNS egy komplex struktúra, ahol külön logisztikát igényel a sejttől, hogy ezt az információt valahogy tárolja.

A DNS ezért nem egy összekuszált fonalgombolyagra hasonlít, amivel három macska játszott, hanem egy kazettákban használt hang szalagra. Ezt kromatinnak hívják. Az előbbi analógia természetesen sántít, mert ha szükségünk van egy dalra, ami a szalag közepén van, folyton tekergetni kell a magnót, hogy mindig azt a részét halgathassuk, amelyiket akarjuk. Ezt az időveszteséget a sejt nem engedheti meg magának, neki úgy kell feltekernie a DNS-t, hogy közben elérhesse azokat a géneket, amelyekre szüksége van. Ezért a kromatin állapot folyton változik a sejt aktuális szükségleteinek megfelelően.

A kromatin még ennél is többet tud! A DNS különböző pontjain fellelhető információnak néha egy helyen és egy időben kell jelen lennie. Mintha a korábban említett kazettán a dalok hangszerei külön lennének felvéve, de lejátszásnál mégis egyszerre hallatszana minden. Ezért a génkifejeződés közben bonyolult térbeli struktúrák jönnek létre, amikor távoli DNS részek közel kerülnek egymáshoz. A Hi-C szekvenálás pontosan ezen struktúrák elemzésére szolgál.

A segítségével megállapítható, hogy egy adott gént milyen távoli enhanszerek szabályoznak. De előszeretettel használják kromoszóma összeépítésre is, mivel ezek a struktúrák általában egy kromoszómán belül jönnek létre és a távolságuk sokkal nagyobb is lehet, mint bármelyik harmadik generációs szekvenálás read hossza.

Először is kovalensen kötik a feltekeredett DNS darabok egymáshoz közeli részeit, ami olyan, mintha pillanatragasztóval fixálnák ezeket a kötéseket. Ezután egy restrikciós enzimmel levágják a hosszú DNS darabokat, amelyek ezekről a fixált részekről lelógnak. Az eredmény tehát egy nagy csomó lesz, amiről rövid DNS láncok lógnak le. Ezeket a szabad láncvégeket összekötik, majd a szekvenálják.

A bioinformatikai elemzés ebből a sajátos laboratóriumi előkészítésből adódóan nagyon eltér a többi második generációs szekvencia elemzésektől. Először is, a read párok távolsága nem követ normál eloszlást, emiatt nem is együtt illesztik őket, hanem mintha külön szekvenciák lennének. Másodsorban a genom adott pontján található read mélységnek nincs információ tartalma. Két genomi pozíció összekötésénél nem az számít, hogy hány read esik egy pontra, hanem hány ilyen pont van, ami megerősíti, hogy kapcsolat van két pozíció között.

Rengeteg program van, amivel feldolgozhatjuk adatainkat, én csak egyet mutatok be, ez pedig a Juicer. Azért ezt, mert erre a protokollra építkezve nem csak a szabályozó kapcsolatokat lehet elemezni, hanem egy genom-összeszerelő módszer is épül rá. Így egy eljárással két bioinformatikai módszert is ismertethetek.

A Juicer nem millió parancssori paraméterrel működik, hanem egy rögzített könyvtár struktúrával dolgozik. Ebbe a könyvátrba helyezzük a references alkönyvtárat a referencia genomokkal, a fastq-t értelem szerűen a fastq fájlokkal. Végezetül a scripts könyvtárba kell helyeznünk azokat a Juicer szkripteket, amelyekkel dolgozni akarunk. Ugyanis a fejlesztők minden platformhoz készítettek egy szkript halmazt, amit különböző alkönyvtárakba helyeztek el (nézzük csak meg a Github repójukat). Például ha csak egy gépen akarunk futtatni, akkor a CPU alkönyvtár szkriptjeit helyezzük el itt. (Vagy csak egy linket helyezünk el). Ez nem egy professzionális megoldás, főleg, ha azt nézzük, hogy már létezik Snakemake. Vitathatatlanul ez az egyik gyengesége a programnak.

Első lépésként a BWA-val indexelni kell a referencia szekvenciát. Ezt nem írom le, gondolom a könyökén jön ki mindenkinek, aki szekvencia feldolgozással foglalkozik.

Ha ezekkel megvagyunk, el kell készítenünk a restrikciós helyek térképét, amihez a Juicer misc alkönyvtárában találhatunk egy szkriptet.

python generate_site_positions.py enzimname reference.fa restrictionfile

Sajnos az enzim nevek a programba vannak égetve. Van HindIII, DpnII, MboI, Sau3AI, Arima. A referenciából kell még készítenünk egy kromoszóma méret táblázatot is, amit a samtools-al készíthetünk el, de csak az első két oszlopra van szükségünk.

samtools faidx reference.fa
cut -f 1,2 reference.fa.fai >reference.chrom.sizes

Ha mindezekkel megvagyunk, indíthatjuk a programot:

scripts/juicer.sh -D workdir -z reference.fa -y restrictionfile -p reference.chrom.sizes

Eredményül fogunk kapni egy .hic kiterjesztésű állományt. Minden további munka, ezzel a fájllal megy.

Rövid vizuális áttekintésre használhatjuk a Juicebox alkalmazást. Javaban írták, és hála a hic tömörített formátumának, akár egy erősebb laptopon is elfut, bár ne reméljünk eget rengető sebességet.

A Juicer egyik kimenetét használhatjuk genom összeszereléshez is, ha referenciának használjuk a scaffoldokat. Ehhez egy másik programra lesz szükségünk, a 3d-dna-ra. Telepíteni nem kell, csak ki kell bontani. A fent említett könyvtár struktúrában a Juicer hatására létrejön egy aligned könyvtár, amiben van egy merged_nodups.txt fájl. Gyakorlatilag erre és a scaffold fájlra van szükségünk. A program támogatja a diploid genom összeszerelést is.

./run-asm-pipeline.sh -m diploid reference.fa workdir/aligned/merged_nodups.txt

Az eredmény a reference.FINAL.fasta lesz.

Természetesen ritka, hogy egy kísérlet hibamentesen fusson. (Ha mégis így van, utóbb kiderül róla, hogy felesleges volt elvégezni.) Szükség van rá, hogy megtudjuk, melyik lépésnél keletkezett a hiba.

Ha az emésztés valamilyen okból nem volt sikeres, akkor azt látjuk, hogy a read párok elhelyezkedése közeli. Közeli alatt azt értem, hogy olyan, mintha egy közönséges DNS illesztés lenne, tehát a fragment távolságok normál eloszlást fognak mutatni.

Ha az emésztés sikerült, de a ligálásnál történt valami malőr, akkor az intrakromoszómális és interkromoszómális fragmentek aránya kisebb lesz. (Az érték egyébként humán vonatkozásban 80 szokott lenni.) Ezt az értéket a Juicer ki is számolja nekünk.

Ha megnézünk egy tipikus Hi-C ábrát, azt látjuk, hogy a főátlóban helyezkedik el a legtöbb fragment, a TAD-ok közelében. Amennyiben nem ilyen az ábra, kezdhetünk gyanakodni, hogy valami gubanc történt.

Felhasznált irodalom:

Bryan R. Lajoie, Job Dekker, Noam Kaplan: The Hitchhiker’s guide to Hi-C analysis: Practical guidelines

Az Experience mindig is egy laza levezetés szokott lenni a partik sorában. Mivel idén nem remekelt a scene, a levezetés is ehhez hasonlatos volt. Csak a legelvakultabbak vették a fáradságot, hogy valamit beadjanak, ezért inkább egyéni, mint csapatversenyt láttunk. Talán ezért is voltak az intrók felülreprezentálva.

Kezdjük mindjárt az első helyezettel, az Ugyanaz mindennel. Számomra nem volt tiszta, hogy mi az, amit ugyanaz. Talán az effektek, amelyeket láttunk már néhány Fresh!Mindworkz produkcióban? Ki tudja? Klasszikus demó annak minden előnyével és hátrányával.

A második Trixy volt, egy 256 byte intró Abaddontól. Ez egy nagyon kedves intró, jó ötlettel, kiváló kóddal. Ez egy igen stílusos búcsúzás az évtől, mert nem túl bonyolult, mégis magával ragadó.

Tifeco ismét egy Demojoe intróval örvendeztette meg a nézőket. Mivel a sztoris alkotásokat előnybe részesítem, ezért majdnem ezt tettem volna meg győztesnek. Az egyetlen hibája talán a nosztalgikus húrok megpedndítése, mert ettől számomra hatásvadásznak tűnik. A scenerek ilyen szempontból olyanok, mint az Oscar-bizottság, akik imádják a filmekről szóló filmeket. Az intró kulisszatitkairól egyébként nemrég irás is megjelent.

Az utolsó helyezett új értelmet ad a "valós idejű animációkan". Egy naplementét láthatunk nagyjából olyan lassan, mintha tényleg a Föld forgását szimulálná. Az egyetlen mentsége, hogy 256 byte intró. A streamen Charlie azt mondta, hogy szerinte remekül összegez mindent 2020 demóiról. Kicsit borulátó megállapítás, de nehéz belekötni.

Nemrég volt egy elég sajnálatos incidens, aminek következtében gyakorlatilag egy hátsó ajtót találtunk a tárhelyünkön.

Az egyik számítógépünkhöz egy külső tárhely van csatlakoztatva. Elsőre elég jó cuccnak tűnt, weben keresztül lehet konfigurálni még a raid blokkokat is. Újraindítás nélkül rendezhetjük csoportokba a vinyókat, sőt, még a hardver hibákat helyét is megmutatja egy képen. Tényleg szuper.

Össze volt kötve a számítógéppel, amin dolgozunk, ezen kívül egy másik számítógéppel, hogy azon keresztül adminisztráljuk, és az internettel, hogy adatokat osszunk meg a kooperációs partnerekkel, ha éppen arra van szükségünk. Én mindig a neten keresztül adminisztráltam, a másik számítógéppel nem sokat foglalkoztam. Az idők során meg is feledkeztem róla.

Egyik nap a főnököm felhívott, hogy "támadják a NAS-t". Minden munkát eldobtam, azonnal beléptem az admin felületre és próbáltam kitalálni, mit tegyek, hogy visszaverjem a támadást. Ilyen szempontból elég kevés eszköz volt, például azt sem láttam, ki kapcsolódik a szerverez. Mivel statikus IP címe volt a tárhelynek, a nagy agyammal kitaláltam, hogy dinamikus IP-t adok neki, mert akkor nem fogják tudni, hol van, ergo nem fogják "támadni".

Be is állítottam. Egy kis számláló mutatta, hol áll a konfigurálás, én meg közben azon gondolkodtam, ha a tárhely dinamikus címet kap, hogyan fogok belépni az admin felületre? Amint rájöttem, hogy hülyeséget csináltam, a képernyő villant egyet, ahogy a böngésző frissítette az oldalt, és a tárhely webes admin felülete eltűnt. De legalább nem támadják - gondoltam.

Utána jött a hír, hogy igazából nem támadta senki a gépet, csupán az rendszeresen felkeresett egy gyanús IP címet, ami a rendszergazdák szerint egy ismert malware update cím. Tehát valaki belépett a tárhely operendszerére és ott futtatott valamit, amit nem kellett volna. Tehát az akciómnak semmi értelme nem volt, mert továbbra is fut rajta a malware. Oké, már csak meg kellene találnom a gépet, mert fene tudja milyen címen van.

Jobb híján az nmap-el fésültem át tartományokat, olyan gépre vadászva, aminek a 8816-os portján egy webszerver üzemel. Aztán eszembe jutott, hogy egy másik gépbe is bekötötték a tárhely egy portját, ráadásul közvetlenül, így teljesen mindegy milyen dinamikus IP-t kapott, a fenti gépen keresztül is el tudom érni.

Elértem, visszaállítottam az eredeti konfigurációt. Szuper, az első ellenséggel, önmagammal leszámoltam. Visszaállítottam a statikus IP címet, kikapcsoltam minden felesleges szolgáltatást, de a tárhely CPU használata szükségtelenül magas volt. A rendszergazdák megerősítették, hogy a gyanús IP-t továbbra is felkeresi. A malware tehát még mindig futott.

Kicsit körbeszaglásztam én is a NAS-t, és láttam, hogy a 22-es port nyitva van. Belépni viszont nem tudtam egyetlen általam ismert jelszóval sem. Arra gondoltam, biztos az SFTP miatt van nyitva. Hiába állítottam le azonban az SFTP szolgáltatást, a 22-es port továbbra is nyitva volt.

Végül nem tudtam mást tenni, mint a gyártó honlapjáról leszedtem az összes elérhető dokumentációt (az egyik 500 oldalas volt), majd frissítettem a firmware-t. A firmware egy 1.7GB-os fájl volt, érzésem szerint a NAS teljes operációs rendszere egy képfájlban, de a formátumára nem jöttem rá.

A firmware frissítés megoldotta a problémát. A CPU használat visszaesett egy 0 közeli értékre, de az SSH port problémáját nem oldotta meg. Márpedig jó eséllyel ott jöttek be a támadók, ezért szerettem volna lezárni.

Közben, csak kíváncsiságból csináltam egy tracerout-ot a kérdéses IP címre az egyik szerverünkről, mire fél órán belül mindenki tiszta ideg lett, mert azt hitték, hogy az a gép is megfertőződött a malware-el. Ahogy Dumbledore is megmondta:

Eltelt pár nap, és én azt hittem, a problémán túl vagyunk, mert a NAS más nem kereste fel a gyanús IP-t, de a rendszergazdák ismét felvették velem a kapcsolatot, mert biztosak akartak lenni, hogy minden rendben van a tárhellyel, és ez az eset nem fog megismétlődni. Igen, kérem, ilyen is van, hogy komolyan veszik a biztonságot. Ők is átnézték a NAS-t, de csak annyit javasoltak, hogy változtassam meg az admin jelszót egy hosszabbra, amit meg is tettem.

Igen ám, de ők is kiszúrták a nyitott 22-es portot. Szerették volna, ha bezárom. Mondtam, hogy nem tudom bezárni, mert az admin felületen nincs rá mód, a jelszót meg nem tudom, hogy parancssorral belépjek és ott oldjam meg a problémát. Átnéztem újra minden dokumentációt, de egy árva szó sem volt ssh-ról benne. Kipróbáltam az általam ismert jelszavakat, de egyikkel sem engedett be.

Kis idő múlva felhívtak, hogy be lehet ssh-zni rootként, ha az 111111 jelszót használják. Hoppá! Kipróbáltam, de szerencsére nem volt ennyire rossz a helyzet, bár már ettől is kirázott a hideg. A jelszó megadása után ugyanis kaptunk egy random 6 karaktert (minden bejelentkezésnél mást), majd egy újabb jelszót kért. Szerintem valami egyszer használatos jelszó mechanizmus lehet.

Ismét átnéztem a dokumentációkat, az internetet, de semmit nem találtam erre vonatkozóan. Végül írtam a NAS gyártójának, hogy ez elég gáz, meg kellene oldani ezt a problémát. Azt válaszolták, hogy ezt az ő R&D csapatuk használja, és nem kell aggódni miatta.

Végül is miért kellene aggódnom? Van egy hátsó ajtó a NAS szerverünkön, amit tud használni a gyártó, tudnak használni fekete kalapos hekkerek, de mi, az üzemeltetők nem. Mintha vennénk egy autót, aminek a csomagtartójába a gyár munkatársai időnként bemásznának, hogy ott kutatás-fejlesztést végezzenek.

Végül leszedtük az internetről a NAS-t. Mostantól nem lesz "cloud" opció, nem lesz adat megosztás kooperációs partnerekkel, de nem lesz titkos nyulka-piszka sem a gyártó R&D csapatától.

Ahogy a konferenciák legtöbbje, úgy a Magyar Bioinformatikai Társaság éves konferenciája is on-line került megrendezésre. Ennek egyik vitathatatlan előnye volt, hogy több külföldön dolgozó magyar kutató is beszélhetett munkájáról. Hátránya pedig (az ingyen kaja hiányán kívül) az informális beszélgetések nélkülözése volt. Nézzük is át, manapság az egyes kutatócsoportokat milyen kihívások foglalkoztatják. A konferencia anyaga itt található.

Korcsmáros Tamás: Hogyan hat a sejtjeinkre a SARS-CoV-2 fertőzés? Hálózatbiológiai vizsgálatok és lehetőségek

A SARS-CoV-2 vírus a fertőzés során egy úgynevezett citokin-vihart okoz, amelynek pontos megértéséhez a jelátviteli mechanizmusok feltérképezése szükséges. A csoport ezen a téren már elég tapasztalatot gyűjtött össze, ezért ezen az úton indultak el. A ViralLink segítségével elemezhető, hogyan hat a vírus mRNS a gazdasejtre. A program számára létfontosságú adatokat az irodalomból szedték össze. Egy másik program, a CytokineLink a sejtek közötti citkokin alapú kommunikációt vette górcső alá. Itt a protein atlaszból megállapították mely sejtek melyik citokin molekulát expresszálják, majd meghatározták a target sejtet az alapján, hogy milyen receptor van a felszínükön. Ezeket az adatokat felhasználva metahálózatokat hoztak létre, ahol szövet-szövet és citokin-citokin kapcsolatok szerepelnek. Az előadás végén a bélrendszeren keresztüli fertőzésről volt szó, ami a vizsgálatok alapján súlyosabb kórlefolyást eredményez.

Manczinger Máté: A kevesebb néha több, avagy miért hátrányosak a generalista HLA molekulák a tumorellenes immunválaszban?

Az adaptív immunválasz során a HLA antigének peptidkötő képessége széles skálán mozog. Amennyiben többféle antigént is képes bemutatni a T-sejtnek, az előnyös egy vírusfertőzés során, mert nagyobb védettséget ad az egyénnek. De mi a helyzet a tumorok esetén? A csoport eredményei szerint a promiszkuózus antigén prezentáló sejt rosszabb immunválaszt vált ki, mert kevés a különbség az egészséges sejtekhez képest. Végeztek RNS szekvenálást is, ahol az alacsony és magas promiszkuitású mintákat hasonlítottak össze. Az eredményül kapott gének GO elemzése T-sejt szabályozással összefüggő géneket írt le.

Makai Szabolcs: Hi-C adatok felhasználásának lehetőségei a genom térbeli szerkezetének leírására az árpa példáján keresztül

A Hi-C adatok a genom különböző pontjai között található kapcsolatokat tárják fel. Gráfelméleti módszerekkel ezek a kapcsolatok vizsgálhatóak. Egy egyszerű, a rugó viselkedésének leírására használt fizikai modellel a kromatin kompartmentek is jellemezhetőek. Az interkromoszómális kapcsolatok modellezésével viszont egy lineáris struktúrát kaptak, amiről az előadónak egy ingasor jutott az eszébe, és ez alapján úgy véli, a működése is hasonló lehet.

Nagy Gergely: A makrofágokat meghatározó transzkripciós faktorok együttműködésének vizsgálata

Nagy mennyiségű chip-seq adatatot elemeztek, és cisztrómokat együttállását vizsgáltak makrofágokban. Sok eredményük már jól ismert irodalmi adatot adott vissza, de az NFE2L2 a MAF-okon kívül más fehérjékkel is tud heterodimert alkotni és cAMP válaszadó elemeket is megköthetnek.

Dankó Benedek: Abnormális transzkripciós mintázatok vizsgálata nagy mennyiségű RNS-szekvenálási adat segítségével mielodiszplasztikus szindrómában

A mielodiszplasztikus szindróma kialakulásában splicing faktor mutációk játszanak szerepet, ezért RNA-seq adatokból olyan splice variánsokat kerestek, amelyek eltérnek a normál szövetektől. Callistot és Salmont használtak az abundancia meghatározására és Iso-kTSP-el nézték az alternatív splice variánsokat. Az előadás fő üzenete az volt, hogy az alkalmazott programok használatától függően eltérő eredményeket kaphatunk.

Kálmán Zsófia: Betegséget okozó mutációk hatásának vizsgálata a coiled-coil szerkezetekre

A coiled-coil moduláris távtartók, állvány fehérjék. A vizsgálatok során az Uniprotból leszedték a fehérje szekvenciákat, a Humsavarból pedig a betegségeket okozó mutációkat. A coiled-coil mutációk többségében idegrendszeri betegségekben fordulnak elő, valamint az erre a régióra eső mutációk kisebb mértékben destabilizáló hatásúak. Ha mégis destabilizáló a hatás, akkor a mutáció a hidrofób magot érinti. Ezen kívül az N terminális régióban található mutációknak kiemelt szerepe van.

Olar Alex: Rheumatoid arthritis betegség automatikus, ízület alapú pontozása röntgen felvételek alapján

A kutatás témája egy Dream challenge-ből indult ki. Az izületi elváltozásokat egy pontozó rendszerrel jellemzik az orvosok, de mivel a kéz minden egyes izületére meg kellene határozni, a gyakorlatban csak nagyon ritkán használják. A versenyben pont az volt a cél, hogy egy algoritmusnak megtanítsák ezt. Először egy neurális hálót használtak az izületek röntgen felvételeken történő azonosítására, majd 12 másikat a predikcióra. A 12 eredményt pedig egy random forest klasszifikációval fűzték egybe.

Radványi Ádám: A standard genetikai kód és kodonmintázatok viszonyának elemzése környezeti adatok fényében: mezofil optimalitás és mutációs trendek

Miért csak egyféle genetikai kód van? A kérdés azért is fontos, mert rajta keresztül az élet eredetére is keressük a válaszokat. Az eddigi vizsgálatok sorra azt állapították meg, hogy az ok abban keresendő, hogy ezzel a kóddal lehet a hibákat minimalizálni. De a kodon használat nem egyenletes a különböző élőlénycsoportok között, mint ahogy ezek a vizsgálatok feltételezik. Ezért ebben a vizsgálatban azt nézték, hogy a kodon használat esetleges hibái hogyan hatnak különböző környezeti feltételek esetén. Azt találták, hogy az extrém magas hőmérsékleten élők esetén egy pontmutáció hatása sokkal súlyosabb. Ezért a genetikai kód valószínűleg a mezofil hőmérsékletű élőlényekre optimális, innen eredhet.

Pajkos Mátyás: Rákbetegségekben mutálódott rendezetlen régiók evolúciós vizsgálata

Az előadás címével ellentétben nem a tumoros megbetegedésekről szól. Az evolúciós vizsgálatokhoz a nagy számú fehérjét valamilyen logika szerint szűrni kellett, ezért csak a tumorokban szerepet játszó fehérjékre korlátozták azt. Megállapították, hogy ezen fehérjék a vizsgálatok szerint ősi eredetűek, a rendezetlen régiók konzerváltak.

Udvarnoki Zoltán: Onkogenetikai elemzések magyar mintákra

A csoport magyar minták onkogenomikai elemzését végzi. A szekvenálástól a szomatikus mutációk annotálásáig minden lépést elvégeznek, az eredményeket pedig egy webszerveren teszik közzé. Az előadás a cBioPortal bemutatásával folytatódott.

Becsei Ágnes: A levegő-metagenomika szerepe a kórokozók monitorozásában

Az előadás egy nagyon nehéz módszert, a levegő metagenomikát igyekezett bemutatni. A nehézséget mi sem bizonyítja jobban, minthogy a csoport nem talált koherens eredményt. Nem találtak plazmidokat, nem találtak horizontális géntranszferre utaló jeleket. Amit találtak, az is erősen szórt.

Farkas Bianka: A CFTR NBD1 mechanikai letekeredésének jellemzése számításos és kísérletimódszerek felhasználásával

A cisztás fibrózis a CFTR génben bekövetkezett mutációra vezethető vissza, aminek van rendezetlen része is. Az általuk vizsgált mutáció hatására a fehérje tekeredése változik meg, amit molekula dinamikai számításokkal vizsgáltak. Eredményeik alapján a leválási időpont változik meg. A hibásan működő domain pontenciális gyógyszercélpont lehet.

Börzsei Rita: A somatostatin 4-es receptor és az endogén ligandum-komplex szerkezetének előállítása

A somatostatis egy neurotranszmitter, ha a receptora hibás, az számos pszichiátriai betegség oka lehet. A vizsgálatban az sst4 receptor és a somatostatin kapcsolódását vizsgálták. Mivel a receptor szerkezete nem ismert, ezért homológ fehérjék alapján próbálták meg felépíteni azt. A dokkolást így sem tudták elvégezni, mert a szerkezet túl nagy volt a szimulációk futtatásához. Ezért az irodalmi adatok alapján a szerkezetnek csak azon részét használták, ami a dokkolásban ténylegesen részt vesz. Eredményeik alapján új somatostatin analógot tudnak fejleszteni, ami gyógyszerként is lehet alkalmazni.

Zsidó Balázs: A TRPA1 receptor ligandumokkal alkotott komplexeinek számítógépes vizsgálata

Az előadás némi átfedést mutat az előzővel, itt is receptor és ligand közötti dokkolást végeztek, de ez egy úgynevezett "szárazdokkolás" volt, "szemiempirikus" paraméter beállítással. Talán emiatt lehetett, hogy a kötési szabadenergiák az irodalomban fellelhető értékeknél 3-4-szer alacsonyabbak voltak.

Csizmadia Georgina: MemMoRF: Lipid kettősréteghez kötődő rendezetlen fehérjerégiók adatbázisa

A lipid kettős réteg és a rendezetlen fehérjék kapcsolatát nehéz vizsgálni, mivel a membrán környezet megnehezíti a vizsgálatokat. Ezért létrehoztak egy adatbázist, ahol az elérhető NMR adatokat felhasználva flexibilitást számoltak és meghatározták milyen másodlagos szerkezetet vehetnek fel a membránhoz kötött rendezetlen fehérjék. Az adatbázis megközelítőleg 500 bejegyzést tartalmaz, és itt érhető el.

Liska Orsolya: TFLink, egy átfogó transzkripciós faktor - target gén adatbázis

Bár már vannak transzkripciós faktor és target gén adatbázisok, ezek nem egységesek, általában csak egy fajra készülnek el. A TFLink egy helyre gyűjti ezeket a több forrásból származó adatokat, és csak kísérletesen igazolt eredmények vannak benne.

Miczi Márió: In silico módszerek alkalmazása a SARS-CoV-2 koronavírus fő proteáz (3CLpro) gazdasejt szubsztrátjainak azonosítására

A vírus proteázok interakcióba lépnek a gazdasejt proteómjával. A vizsgálat célja a 3CLpro proteáz humán célpontjainak meghatározása. Mivel erről a proteázról kevés információ van, ezért Blast segítségével homológokat kerestek és azok segítségével határozták meg a potenciális célpontot. A NetCorona webszerverrel pedig a hasítások helyét állapították meg. Az eredményeket in-vitro validálták, de sok esetben más eredményt kaptak. Vagy nem volt hasítás, vagy máshol volt, mint ahogy a predikció jósolta.

Palla Gergely: Metilációs hálózatok hierarchikus és kontroll tulajdonságai

A DNS metiláció szintjével jól lehet jellemezni az öregedést. Ezen alapul az úgynevezett Horvath-féle óra is, ami egy az ismert epigenetikai órák közül. Ezért ez a vizsgálat arra irányult, hogy a CpG metiláció szabályozásának hálózatát térképezzék fel. Erre egy regularizált Lasso-regressziót használtak, ahol akkor hoztak létre éleket a gráfban, ha ez a regressziós érték nullánál nagyobb volt. Az így elkészült hálózat hierarchikus volt, ahol a hierarchia tetején olyan gének szerepeltek, amelyek jobban beleszólnak az öregedés szabályozásába, mint a hierarchia alján lévők.

Kerepesi Csaba: Egér öregedés és megfiatalodás mérése epigenetikai órákkal

Az előadás több ponton is kapcsolódik az előző témához. Itt is az epigenetikai életkorral összefüggő vizsgálatok történtek, de jóval gyakorlatiasabb módon. A csíravonal sejteknek van egy olyan állapota, amikor "megfiatalodnak", vagyis a metilációjuk a fiatal sejtek állapotára hasonlít. A csoport egy olyan gépi tanuláson alapuló epigenetikai órát fejlesztett ki, ami nem csak az életkort becslüli meg nagy pontossággal, hanem az egyes életkor befolyásoló kezelések hatását is.

Fiser András: Aminosav alapú farmakofór módszer fehérje kölcsönhatások vizsgálatára

Ahogy a korábbi előadásokban is láthattuk, a fehérje kölcsönhatásokat dokkolással szokták vizsgálni. A dokkolás ismert kapcsolódásokon alapul és egyszerűsítéseket tartalmaz. A csoport kifejlesztette a ProtLID módszert, ami kiküszöböli a fenti limitációkat, cserébe nem az egész fehérjét, mint egységet nézi, csupán az aminosavakat. A szimuláció lényege, hogy a fehérjéből csak azokat az aminosavakat vizsgálja, amelyek potenciálisan részt vesznek a kötésben. A módszer az antigén-receptor kötéseket jobban képes leírni, mint a hagyományos dokkolás alapú módszerek.

Albert István: Bioinformatika és Egyéb Problémák

Az előadás azt mutatta meg, hogyan akadt az előadó egy bioinformatikai elemzés hibájára, amit úgy jellemzett "nekem egy órába telt, másnak talán több időbe". A probléma az volt, hogy az RNS szekvenálás irányított volt, de a Galaxy-ban rosszul klikkeltek egy paraméterre, amitől a readek irányát fordítva vizsgálták. Ettől két gén abundanciáját rosszul határozták meg, amelyek átfedtek, de ellenkező szálon voltak. A megoldást az adta, hogy az IGV-ben be kell állítani, hogy színezze be a readeket orientáció szerint. Ezután még olyan jótanácsot is hallhattunk, hogy a jó bioinformatikus tudja, mit jelentenek a paraméterek, amelyeket beállít a programokban.

Toth Adrienn előadását sajnos nem tudtam végignézni, ezért arról nem írok összefoglalót.

Amikor a számítógépeket használjuk, hajlamosak vagyunk (na, jó, hajlamos vagyok) azt hinni, hogy a kiszámított értékek teljességgel pontosak. A valóság viszont az, hogy csak egy közelítést adnak. Alkalmanként nem is olyan közelit.

Már eddig láttam jeleket, hogy a számítógépek máshogy viszonyulnak a számokhoz. Ha megnéz az ember egy 256b Mandelbrot fraktál zoomert, akkor előbb-utóbb azt tapasztalja, hogy a lebegőpontos számításhoz használt értékek elérik végső határukat, nevezetesen a fraktál egy színű lesz. De nem kell egy demoscene rendezvényre elmenni, hogy mindezt lássuk. A Python híresen rosszul kezeli a lebegőpontos számokat. Próbáljuk csak ki az interaktív konzolba beírva:

>>> 6.89 + 0.1
6.989999999999999

Az egyik legutóbbi feladatomnál Fisher tesztet kellett végeznem, viszonylag nagy számokra. A kontingencia táblázatban alkalmanként 200 milliós érték is lehetett! Az elvégzendő tesztek száma pedig olyan nagy volt, hogy nem akartam R-el vesződni. Igen, kicsit sok adat gyűlt össze. A teszt végeredményének kiszámításához faktoriálisokat kellett használni, és itt kezdődtek a problémák.

Ha csak a naív módszert használjuk, hamar rájövünk, hogy a 64 bites lebegőpontos számokkal 142-nél nagyobb faktoriálist nem lehet kiszámítani. Ráadásul a Fisher tesztben nem egy faktoriális szerepel, hanem faktoriálisok szorzata! Ezért a régi, jól bevált módszerhez folyamodtam: Nem szoroztam, hanem az értékek logaritmusát adtam össze. Mindjárt elég volt a hely, hogy akár 200 milliónak is kiszámítsam a faktoriálisát.

Ezzel viszont a pontosság rovására mentem. Ha megnéztem, milyen eredményt ad ki az R, akkor a nagyságrend stimmelt, viszont az értékek köszönő viszonyban sem voltak. A sebesség is gyatra volt. Egy teszt kiszámítása  kb. 4 másodpercet vett igénybe. Az összes teszthez két hónapra lett volna szükségem!

Lassú és rossz. Ezt a kombinációt akartam elkerülni. De mit lehet tenni ilyen esetben? Tisztázni kell a célokat. Igazából nem muszály manuálisan kiszámítani a faktoriálisokat, van egy közelítő eljárás, a Strigling módszer. Nem ad pontos eredményt, de nagyon gyorsan adja vissza. Egy gyors összehasonlítás a korrekten kiszámított értékekkel azt mutatja, hogy már alacsony értékeknél is lehet eltérés.

Egy közelítő értékeket használó statisztikai teszt, ami gyors és rossz. Lehet ebből jó eredmény? A válasz az, hogy igen. Ugyanis nekem azt kell eldönteni, hogy az asszociáció létezik-e két jelenség között. Tulajdonképpen nem számít, hogy ez az érték 3,4e-14, vagy 5,6e-12, amíg ebben a nagyságrendben mozognak. Ezt viszont a közelítő értékekkel is meg tudom állapítani.

Azért annyit változtattam a faktoriális kiszámító eljárásomon, hogy ha 10-nél kisebb számot adok meg neki, azonnal visszaad egy előre tárolt értéket. Ha 10 és 120 közötti az érték, akkor pontosan kiszámítja (ha eltekintünk a kerekítési hibáktól), és csak ennél magasabb érték esetén használja a közelítő formulát.

A program olyan gyors lett, hogy a másodperc tört része alatt megkaptam az összes eredményt. (Utána jutott eszembe, hogy elég lenne a legnagyobb szükséges értékre kiszámítani a faktoriálist és az összes köztes értéket tárolni egy tömbben, az gyors is lenne és pontos is.)

Ettől függetlenül látható, hogy a számítás módja meghatározza az eredményeket. Ez nem csak nálam érhető tetten, a nagy cégek által írt programoknál is fontos. Ha megfeledkezünk az Excelről, akkor is marad elég példa. Sőt, ahogy változik egy API verziószáma, úgy áttérhetnek más számítási módszerre is. Érdemes résen lenni, és sűrűn olvasni a dokumentációt.

Azért elgondolkodtató, hogy mennyire ismerhetjük meg a valóságot. Hiszen nem csak a számítás torzításán keresztül látjuk a világot, hanem azt is el kell dönteni, milyen torzítást használjunk. De biztosan tudom a kiválasztott módszer összes hátrányát? Nem lehet, hogy további meglepetések várnak rám, csak a megértésem még nem jutott el arra a szintre?

Az én példámnál maradvan, nem a Stirling az egyetlen közelítő eljárás. Választhattam volna mást is, amely más tulajdonságokkal bír. Ez még csak a faktoriálist. Erre épül a Fisher tesztem, ami ha egyszerűsítést nem is, kerekítési hibákat tartalmazhat.

Mi a jobb? Megállni biztos távolságra az ismeretlentől, és kijelenteni: eddig a pontig mindent ellenőriztem, amit itt találtam, az megbízható. Esetleg a hiányosságok ellenére is tovább menni, és remélni, hogy amit látok, az egy új eredmény, nem pedig a szemüvegem torzításának a felnagyítása?

A rövid válasz a fenti kérdésre, hogy mindkettő. Twitteren, blogokon, szakmai fórumokon rendszeresen felbukkannak hasonló kérdések (a leghíresebb talán a Python vs R vita), ahol rendre megjelennek olyan írások, hogy egyik vagy másik programozási nyelv felsőrendűbb a másiknál.

Nekem ezekre a vitákra egyetlen válaszom van: egy profi nem engedheti meg magának, hogy csak egyetlen eszközt ismerjen. A hátukgombolósok meg csak vitázzanak.

A jó kérdés inkább az, hogy mikor érdemes használni egyik vagy másik nyelvet? Mert ez nem mindegy.

Még nem vagyok egyik nyelv mestere sem, hiszen pár hónapja vetettem bele magam a tanulásukba, de azért kezd kirajzolódni egy kép bennem, hogy mely területeken lesz érdemes használnom ezeket.

Közös a két nyelvben, hogy az implementációk nem csak a fordító programot tartalmazzák, hanem a függőségek kezelését is. Más nyelvekben ez külön program szokott lenni. Például a Maven a Javahoz. A másik, hogy a fordító több feladatot vesz át a kód ellenőrzésből.

Természetesen különbségek is vannak. Kezdjük a Rust-al. A Rust egy második C akar lenni, ezért mindenhol, ahol korábban C-t használtunk, használhatunk Rust-ot. A nyelv megtanulása nem egyszerű, bár az is lehet, hogy én kötődök a hibás sémákhoz, amelyek értelem szerűen nem megengedettek Rust alatt. A kód fordításáért nekem meg kell szenvedni.

A C-vel való kompatibilitásnak ára is van, ezért lehetőséget adnak a fejlesztőnek arra, hogy "nem biztonságos" kódot is írjunk. (Bár szerény véleményem ez a biztonságos kódírásról. Még akkor is, ha elég sokszor lábon lőttem már magam)

Minden esetre, ha elsajátítottuk a nyelvet, könnyedén át tudunk térni Rust-ra, fokozatosan átírva egy projektet. Hangsúlyozom, miután elsajátítottuk. A tanulás hosszú időt vesz igénybe, később fogunk csak örülni az eredménynek. Még a nagy projektek is most vizsgálják, mennyire képes leváltani a nyelv akár a C++-t is.

Ezért a Rust például alkalmas lehet demók írására, mert van OpenGL könyvtár, van idő kísérletezni és jó, ha a végeredmény nem fagy le, mert nem figyeltünk eléggé az erőforrások felszabadítására.

A Go ezzel szemben nem törekszik arra, hogy a mindenség egyetemes nyelve legyen. A Google Cloud nyelvként definiálja, ami nem tudom, mit akar jelenteni. Amit tudok, hogy a Rustnál gyorsabban megtanulható, mert a nyelvi szintaxis egyszerűbb. Támogatja a többszálú feladat végrehajtást, amit remekül ki lehet használni a mai többmagos gépeknél, a fordítás után kapott bináris pedig statikusan linkelt. Ez utóbbi miatt könnyebben lehet horozni a binárist különböző Linux disztribúciók között.

A könyvtárak száma ezzel szemben limitált. Véleményem szerint soha nem fogunk Go alatt grafikus felületű programokat fejleszteni. Ha megnézzük az elérhető könyvtárakat ilyesmiket találunk: hálózatok, titkosítási eljárások.

Ezek a tulajdonságokat remekül lehet bioinformatikai programok fejlesztésére használni. Mire van legtöbbször szükség? Konzolos alkalmazásokra, amelyek beolvasnak egy fájlt és létrehoznak egy másikat. Esetleg adatokat kell letölteni az internetről. Sokszor kell nagy mennyiségű adatot feldolgozni, amihez elengedhetetlen, hogy több processzor magot is használjunk. A Go pedig mindezt tudja.

A TV adás nálunk egy Horizon médiaboxon keresztül érkezik. Sokáig nem is foglalkoztam vele, mert nálunk a TV-zés kimerül a napi Mancs Őrjárat megtekintésben. Néha vannak különleges napok, amikor iszonyat töménységben adnak le részeket, és ezek megtekintése még a legnagyobb rajongóknak is komoly megterhelést jelent, szegény szüleikről nem is beszélve.

Szerencsére a médiaboxhoz lehet vinyót csatlakoztatni USB-n keresztül, és fel lehet venni a részeket. Elkezdett érdekelni, vajon a felvett tartalmakat át tudom-e rakni számítógépre, és ott le tudom-e játszani. Abból indultam ki, hogy a doboz gyártói bizonyára nem kezdtek el saját formátumokat kitalálni, hanem meglévő komponensekből építkeztek.

Először a netet túrtam fel, de csak a szolgáltató felületes leírásai jöttek fel találatként. Talán senkit nem foglalkoztat a probléma?

A vinyót egy Linuxos laptophoz csatlakoztattam és sikerült megnézni a fájlrendszert. Ahogy elsőre számítottam rá, érthetetlen könyvtárnevek és ismeretlen fájl kiterjesztéseket találtam. Amin először meglepődtem, hogy a vinyón ext4 fájlrendszer volt, holott a leírások FAT32-t kérnek. Nocsak, nocsak. Bizonyára ezzel a primitív trükkökkel akarták megakadályozni a Windowson szocializálódott embereket, hogy TV műsorokat lopjanak.

Az első érdekes fájl a recordings volt. Linux alatt van egy file nevű parancs, amivel elég sok fájl típusát meg lehet mondani. De ennél egy közönséges less is elégnek bizonyult, ha nem ijedünk meg az ASCII karakterek tengerétől. A fájl ugyanis egy SQLite 3 adatbázis!

Ezt könnyedén be lehet olvasni, ha rendelkezünk a megfelelő adatbázis kezelővel:

sqlite3 recordings

Ebben az adatbázis kezelőben a .tables paranccsal kilistázhatjuk a táblákat. A felvételek a nagyon beszédes nevű recordings táblában vannak. A szerkezetét is megnézhetjük:

.scema recordings

Bár elég sok ismeretlen elemet láthatunk, rövid nézelődés után találhatunk egy path mezőt, ami alapján megtalálhatjuk a videó fájlokat. Persze a semmitmondó könyvtárakban úgyis a legnagyobb fájl tartalmazza a videókat, de ha specifikusan keresünk valamit, akkor az adatbázisból könnyedén ki lehet keresni a megfelelő felvételt.

Ezután jött a nagy kérdés, hogy micsoda a .rec kiterjesztésű fájl? Sem a less, sem a file parancs nem tudott érdemi választ adni. Elkezdtem bújni a netet, hátha találok valami érdekeset. Amitől nagyon féltem, hogy valami ostoba titkosítást fognak használni, ami lehetetlenné teszi, hogy használni lehessen a felvételeket.

Annyit sikerült találnom, hogy ez egy Toppy formátum, de ami felcsillantotta a reményt, hogy a VLC lejátsza. Akkor talán az MPlayer is!

Kis is választottam egy tetszőleges fájlt, de nem jelentek meg a kutyik, csak színes négyzetek villództak, mint a hibás MPEG2 videók esetén. Elkezdtem ismét a netet bújni, amikor a feleségem megkérdezte, mit csinálok. Neki is megmutattam a lépéseket, de a videó fájl kiválasztásánál egy másik példát választottam.

Megdöbbenésemre megjelent a mese! Hmm. Mint kiderült, két-három esetben valami miatt nem sikerült a felvétel, és nem lehetett visszajátszani. Többségében viszont az Mplayer (VLC is) zokszó nélkül lejátsza azokat.

Az ext4 fájlrendszer és az SQLite3 arra utal, hogy ebben a médiaboxban egy Linux dorombol. Vagy fene tudja, milyen hangot adnak ki a pingvinek.

2020 sok új szót hozott nekünk: nyunyóka, Mortran, QAnon. Mi? Ti nem tudjátok, mi az a Mortran? Akkor azt sem tudjátok, hogyan dolgozik egy igazi Nobel-díjas? Elmagyarázom.

Először is, meg kell szerezni a Nobel-díjat. Miből? Teljesen mindegy. A díj megszerzése ugyanis autómatikusan feljogosít arra, hogy az illető mindenhez értsen. Ehhez adjunk hozzá egy világjárványt, amihez egyéként is mindenki ért. A kettő együtt már jó alap arra, hogy bármilyen hülyeséget is mondjunk, arra mindenki figyelni fog. Újságok írják meg, miniszterelnökökkel találkozhatunk, akiknek személyesen mondhatjuk el. Ha egy-két jóslatunk véletlenül be is jön, az csak jó.

Nem hiszitek? Ezt csinálta Michael Levitt is. Az életműve előtt le  a kalappal, hiszen a hatvanas-hetvenes években komplex molekulák számítógépes modellezésével foglalkozott. El lehet képzelni, milyen hardver és szoftver környezettel dolgozhatott, úgyhogy abban alkotni maradandót, nem kis munka. Ezzel nem is akarok vitatkozni. De, ami azután jött, az már nem ilyen elismerésre méltó. A járvány kitörésével ugyanis COVID szakértő lett, és lépten-nyomon hangoztatta is jóslatait.

Viszont ezzel a tudományos közösséggel valami baj lehet, én mondom. Nem volt nekik elég a sok nyilatkozat, kijelentés, előrejelzés, amit Levitt tett. Azt is tudni akarták, mégis mi az alapjuk ezeknek a jósnatoknak? Nem azért, mert annyira pontosak voltak, hanem ellenkezőleg, mert úgy tűnt, semmi közük a valósághoz. Például az Egyesült Államokban négy hét alatt vége lesz a járványnak, 170 ezer halottal. Ha pedig egy ilyen befolyásos ember mond hülyeséget, annak következményei vannak, gondoljunk csak a C-vitaminra és a megfázásra.

A nagy unszolásnak az lett a vége, hogy született egy kézirat, ami a szokásos csontot veti oda a nyílt tudomány híveinek: minden adat és kód nyilvános lesz. Hol és mikor, az már egy más kérdés. Ezek a hátul gombolós tudósok folyton ilyen apróság miatt hisztiznek. De azért így is érdekes dolgokat tudhatunk meg. Például Levitt Mortranban kódol. Nem kell félni, nekem is kiadós utánajárást jelentett, ami azt jelenti, mégsem vagyok olyan öreg. :-) Ez a csökevény még '75-ből maradt ránk, a trapéz gatya és a hippi hajviselet korából. Tudom, hogy régi programnyelv, nem vén programnyelv. Azt is tudom, hogy a COBOL is milyen értékes lett. De bárki, aki számítógépekkel foglalkozik, lépést kell, hogy tartson azok fejlődésével is, nem igaz? Ha pedig programozik, akkor a programozási nyelvek fejlődésével is. Nem baj, ha valaki szereti a Fortrant, de akkor tartson is lépést vele!

Azért nehogy azt higgyük, ez az ember képtelen a fejlődésre! A cikk következő bekezdésében megtudjuk, hogy Levitt másik kedvenc programozási nyelve egy elavult Perl. Nem kéne ilyen szigorúnak lennem vele, lehet, hogy magabiztosan kezeli a Python 2.3-t is...

Nem sokat tudok a Mortranról, de valószínűleg manapság nem lehet binárist készíteni vele, hiszen a kéziratban is azt írták, hogy átfordították C-re. De mi is az a nagy titok, amit ebben a nyelvben fejlesztettek? Mi lehet az, amit csak Mortranban lehet megoldani? A válasz nem más, mint a loess normalizálás. Ez nem más, mint egy közönséges görbe simító eljárás, amit ilyen ujhullámos nyelvekben, mint R és Python rutinszerűen szoktak meghívni. Nos, a szerzők találtak egy '76-ból származó Fortran kódot (biztos az egyik szalagos egységen pihent), amit átírtak Mortranba. Igen, abba a Mortranba, amit végül C-re fordítottak.

Így dolgoznak az igazi nagyágyúk. Ezek a mai tejfölös szájú mitugrászok meg jönnek a deep learninggel, meg virtualizációval, hogy mindent a nyomorult felhőben futtassanak. Még egy nyamvadt Mortran kódot sem tudnak összedobni. Bezzeg régen! A mai fiatalok azt hiszik, hogy a forráskódból olyan természetességgek jönnek létre a binárosok. Klikkelgetnek az IDE-n aztán deployolnak operációs rendszertől függetlenül? Régen nem így volt. Régen a binárisért meg kellett szenvedni, és aki nem szenved meg érte most, az nem is tudja értékelni azt! Van még mit tanulni.

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

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.

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ű.

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.

Ú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.

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.

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.

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.

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.

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.

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".

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.