Az utóbbi időben játszottam egy keveset az Illumina saját fejlesztésű programjaival. Ez idő alatt sokszor eszembe jutott a régi vicc, csak Szadlacsek helyett az Illumina nevével.
Az Illumina a TSO 500 paneljéhez egy saját alkalmazást is fejlesztett, ami a felhős körnezetében, a BaseSpace-en fut. Ez egy nagyon jó panel, hiszen egyben csinál DNS és RNS szekvenálást, keres mutációkat, fúziós proteineket, kópiaszám változásokat. Mivel egy targetált szekvenálásról van szó, ezért a futási idő is baráti, egy 24 processzorral 10 óra alatt eredményeket kaphatunk.
A BaseSpace viszont nem ingyenes. Miért kellene azt használnunk, ha eleve van egy nagy, VMWare-el felszerelt szerverünk? Szerencsére nem is kell, mert van Local App, amivel ott, és akkor futtatunk, amikor csak akarunk.
Ezzel nem is volt addig gond, míg a gyártó által használt programokat, a gyártó által használt szekvenáló kitekkel, és szekvenáló berendezéssel használták. Hanem, amikor kitalálták, hogy a szekvenáló gép nagyobb áteresztő képességű legyen, akkor az egész munkafolyamat megnyekkent. Az Illumina support széttárta a kezét, a csoport a problémájával magára maradt.
Ekkora kaptam meg a feladatot: TSO 500 Local App elemzés nem támogatott szekvenálási platformon. A Local App nem más, mint egy Docker konténer, amibe az összes szükséges program megtalálható. A telepítő nem csak a programokat, hanem a referencia genomokat és indexeket is tartalmazza.
Az Illumina szekvenáló gép nem FASTQ-t ad eredményül, hanem egy BCL formátumú fájlt, millió egy körítéssel, amiből a legfontosabb a SampleSheet nevű CSV állomány. Ha a Base Space-ről letöltjük a szekvenálás eredményét, ezt fogjuk megkapni.
A BCL egy tömörített formátum, ami nem csak a nukleotidot és a hozzá tartozó minőségi pontszámot tartalmazza, hanem egyéb információkat is, például, hogy mekkora a valószínűsége az alernatív nukleotidok előfordulásának, leolvashatóak a különböző index szekvenciák is, stb. A mindennapi munka során ezekre az információkra nincs szükség.
A Local App alapértelmezetten a BCL fájlokkal dolgozik. Eredményül pedig VCF-eket, táblázatokat és egyéb eredmény fájlokat ad vissza. Viszont lehetőség van arra is, hogy a FASTQ fájlokon végezzük el az elemzéseket. A feladatot ezért két részre lehetett bontani. Először a BCL fájlokat kell FASTQ-vá konvertálnom, majd ezeken a fájlokon kell lefuttatni az elemzéseket.
A BCL fájlok konvertálását a bcl2fastq vagy a bcl-converter nevű program végzi. Előbbi egy régebbi verzió, ha csak tehetjük, kerüljük el a használatát. A Local App is a bcl-convertert tartalmazza. Ha külön akarjuk telepíteni, akkor egy rpm csomagot tudunk csak letölteni. Szerencsére Ubuntu alatt az alien csomag megoldja az rpm telepítését. A bcl-converternek csak a szekvenálás során keletkezett könyvtár halmaz belépési pontját kell megadni, a többit elvégzi ő maga. Megkeresi a SampleSheet.csv-t, majd ez alapján szétbontja a szekvenciákat a mintákra.
Itt kezdődtek a bajok. Mivel a szerverre a bcl2fastq volt telepítve, azt kezdtem el használni. De az nem ismerte fel a SampleSheet.csv-t.
A SampleSheet.csv egy olyan fájl, amit a Windows-os INI fájlok és a CSV szerelem gyerekének is tekinthetjük. Alapvetően egy vesszővel tagolt táblázat, de szekciókra van tagolva. Minden szekció egy szögletes zárójelbe írt névvel kezdődik. A két legfontosabb szekció a Settings és a Data. Természetesen azoknál a szekvenciáknál, amikkel én dolgoztam, ezek a szekciók nem léteztek. Volt helyette Cloud_Data és BCL_Settings.
A SampleSheet.csv-nek is van verziója. A Data és Settings az 1-es verzióban van, a 2-ben ilyenek nincsenek. Talán két napom is ráment, mire egy doksiban ráakadtam, hogy a bcl2fastq-t nem érdemes használni, mert régi. A bcl-convertert kell, mert az megeszi a régi és az új SampleSheet.csv formátumot is. A vicces az volt, hogy a bcl2fastq-val nem kaptam hibaüzenetet, csupán az összes read egy Uncategorized nevű fájlba ment, jelezve, hogy az indexek leolvasása hibás volt.
A SampleSheet-ben ugyanis fel van sorolva az összes minta neve, valamint az index szekvenciák, ami alapján el lehet különíteni őket. Tetszőleges szekvenciát nem írhatunk bele, mert a Local App ellenőrzi az erőforrásai között, hogy érvényes-e a nukleotid sorrend.
A konvertálás után viszont nem futott le az analízis, mert nem találták az elemző programok az UMI szekvenciákat. Ezekről az egyedi molekula azonosítóktól már korábban írtam. Ahhoz, hogy az elemzés korrekt módon lefusson, meg kell adni ezeknek a szekvenciáknak a helyét a read-en belül. Erre szolgál az OverrideCycles beállítás a SampleSheet-en belül.
A paraméterek elég kriptikusak. Egy I, Y, U betű plusz szám kombinációk vannak felsorolva pontosvesszővel elválasztva. Valami miatt az újabb keletű dokumentációkban nincs leírva róla semmi, én is egy korábbi PDF-ben bukkantam rá. Ezzel lehet megadni az UMI szekvenciák és a minta szekvenciák hosszát és egymáshoz viszonyított helyzetét.
Valamint kell még a TrimUMI,0 beállítás is, amivel megtartjuk az UMI szekvenciákat, mert hiába nélkülözhetetlen ez a szekvencia minden elemzéshez, a program alapértelmezetten levágja.
Valami miatt a fenti beállítások csak az 1-es verziójú SampleSheet-ben működnek. Erre a rejtélyre nem tudtam rájönni, miért van, de tényleg csak így megy.
Az elemzés futtatásához pontosan ugyan az a SampleSheet kell, mint amivel a FASTQ fájlokat előállítottuk, mert ha nem így van, akkor minden lépés gond nélkül lefut, de az eredmény fájl üres lesz. A szekvenciáknak a minta nevét viselő alkonyvtárakban kell lennie. Elméletileg a bcl-converter ezt el tudja készíteni, de csak akkor, ha egy újabb oszlopot felveszünk a SampleSheet Data szekciójába. Nekem ehhez nem volt kedvem, helyette a következő bash paranccsal láttam el a baját:
for i in `ls *R1*`
do
export j=`echo $i | sed 's/_S[0-9]\+_L001_R1_001.fastq.gz//'`
mkdir $j
mv $i ${i/_R1_/_R2_} $j
done
Ezek után minden készen áll, hogy lefuttassuk az elemzést.
sudo /opt/LocalApp/TruSight_Oncology_500_RUO.sh --fastqFolder /path/to/fastq --analysisFolder /path/o/results --resourcesFolder /path/to/resource --sampleSheet /path/to/samplesheet.csv --isNovaSeq
A munka során végül hozzájutottunk a Local App 2.2-es verziójához, ami jelentősen leegyszerűsíti a futtatást, mert a FASTQ-k előállításához is használhatjuk a docker képet. Valahogy így:
sudo /opt/LocalApp/TruSight_Oncology_500_RUO.sh --runFolder ./fastq --analysisFolder /path/to/fastq --resourcesFolder /path/to/resource --sampleSheet /path/to/samplesheet.csv --demultiplexOnly --isNovaSeq
Amennyiben valami gond történt, megnézhetjük a napló fájlokat. Az eredmény könyvtárban minden egyes lépéshez tartozik egy alkönyvtár, amiben megtaláljuk a log fájlokat. Mint korábban írtam, a legtöbb esetben a hibák ellenére is lefut a teljes elemzés. A másik gond, hogy a hibaüzenetek nem mindig takarják az igazi okot. Például én sokáig nem tudtam mit kezdeni azzal a hibaüzenettel, ami arról szólt, hogy a fastq könyvtár nem található. Kiderült, hogy csak jogosultság problémáról van szó, és nem rosszul megadott elérési útról.
Egy másik alkalommal a SampleSheet fájl formátuma nem volt megfelelő. Egy sorban elfelejtettem kitenni a vesszőt. A program a SampleSheet összes sorát hibásnak jelölte.
Ha röviden kellene összefoglalnom, akkor az Illumina programjainál mindig használjuk a legújabb verziót, és az eggyel régebbi dokumentációt.
