SPECIALE UDVIKLING AF EN METODE TIL ALIGNMENT AF HELE GENOMER 29. MARTS Aarhus Universitet Datalogisk Institut

Transkript

1 Aarhus Universitet Datalogisk Institut SPECIALE UDVIKLING AF EN METODE TIL ALIGNMENT AF HELE GENOMER 29. MARTS 2010 VEJLEDER: CHRISTIAN NØRGAARD STORM PEDERSEN POUL LIBORIUSSEN ( ) OG STEFFEN MIKKELSEN ( )

2

3 Development of a whole genome alignment method Poul Liboriussen and Steffen Mikkelsen 29. marts 2010 Abstract In this thesis we present a whole genome aligner capable of aligning two chromosomes of 145 mega basepairs in less than two hours on a normal workstation. The challenge of aligning whole chromosomes or genomes, is that both small-scale and large-scale evolutionary events have to be considered. Smallscale events introduce small changes in the DNA, such as insertions, deletions, and mutations of nucleotides. Large-scale events can change the placement and orientation of large chunks of chromosomes. Our approach to genome alignment is inspired by the genome alignment tool Mauve, but differs, mainly by focusing on using parallelism to reduce the practical time needed. On an 8-core machine we are able to outperform even the fastest version of Mauve when aligning nine bacteria genomes. We have evaluated our implementation against three different versions of Mauve and Shuffle-LAGAN, which, to our knowledge, are the only programs capable of making whole genome alignments. We have used both real data sets and our own sequence simulator to verify that our implementation and alignments are comparable to the newest version of Mauve. ii

4 INDHOLD Indhold iii 1 Indledning 1 2 Evolution og alignments Evolution af genomet Alignment af sekvenser Algoritmer for parvis alignment Algoritmer for multiple alignment Heuristisk multiple alignment Multiple alignment med large-scale-events Valg af metode Udvikling af Prototype Ankersøgning med seed-and-extend Gruppering af MUM s i kolinære blokke Gapped alignment Evaluering af Prototype Udvikling af Draft Introduktion til CLC bio s framework Ankersøgning med seed-and-extend Gruppering af MUM s i kolinære blokke Iterativ ankersøgning Gapped alignment Evaluering af Draft Udvikling af Final Pash MUM s for delmængder af sekvenser Optimering af endelig udgave Opsummering af Final iii

5 iv INDHOLD 6 Resultater Korrekthed af implementering og alignment Alignmentkvalitet Måling af hukommelsesforbrug Måling af tidsforbrug Testmaskiner Valg af data Udvikling af sekvenssimulator Endelige resultater og evaluering Konklusion og fremtidigt arbejde Konklusion Fremtidigt arbejde Taksigelser Kildekode Arbejdsfordeling A Supplerende materiale 115 A.1 Antal genomer tilgængelig per år B Ekstra resultater 117 B.1 Hukommelsesforbrug C Datasæt 119 C.1 Ni bakterier fra Mauveartiklen C.2 Eukaryotiske datasæt C.3 Datasæt fra sekvenssimulator Litteratur 123

6 K A P I T E L 1 INDLEDNING Den eksponentielt stigende mængde af sekventerede genomer gør analyseværktøjer essentielle, for at kunne sammenligne og annotere nye genomer, i takt med at de bliver tilgængelige. Analyse af disse store datamængder kræver nye, effektive tiltag og metoder for at være praktisk muligt. Alignment af genomer er et af de centrale værktøjer, brugt til indledende studier. En alignment viser bevarede elementer mellem to eller flere dna-sekvenser. Man er altså interesseret i at sammenligne nye sekventerede genomer med tidligere undersøgte, for således hurtigt at kunne identificere bevarede regioner. Disse sammenligninger er interessante da de danner grundlag for eksempelvis evolutionære analyser, annotering af sekvenser og forståelse af fænotypen. Sammenligningen af mindre områder af genomer indeholder kun såkaldte small-scale-events, hvor enkelte nukleotider kan være muteret, fjernet eller tilføjet. For hele genomer kan traditionelle alignment-algoritmer ikke længere benyttes. Det skyldes at hele genomer gennemgår såkaldte large-scale-events, som er evolutionære begivenheder, der flytter dele af genomet til et andet område. Mauve [5] er navnet på en algoritme, lavet til at aligne to eller flere genomer, der har undergået både small- og largescale-events. Algoritmen er baseret på identifikation af fælles delsekvenser mellem genomerne, kaldet ankre. Ved at have ankre i sekvenserne, kan man reducere problemet til en række af mindre alignments, hvilket er meget hurtigere at løse rent algoritmisk. Herudover kan ankrene bruges til detektion af large-scale-events. Mauve er algoritmisk set, en samling af heuristisk strengalgoritmer, der er lavet med henblik på at være anvendelige i praksis. Dette speciale har til formål at opnå indsigt i Mauve, samt at lave en implementering, der anvender centrale dele af algoritmen. 1

7 2 KAPITEL 1. INDLEDNING Målet var en genomaligner der kan anvendes på hele kromosomer, på størrelser der minder om kromosomer for mennesket, da dette i praksis er et hyppigt anvendelsesområde til analyser. Vi ønskede at ligge på niveau med Mauve 1, hvad angår både kvalitet og praktisk udførelsestid. Vores implementering er skrevet i Java og vi har ud over vores målsætning, også forsøgt at gøre implementeringen i stand til at kunne aligne hele kromosomer på maskiner, med en begrænset mængde hukommelse til rådighed. Vores implementering af en genomaligner støtter sig primært til Mauves artikel, dog med samtidig inddragelse af relateret litteratur, for at perspektivere og give ideer til forbedringer af algoritmen. Implementeringen lavede vi i samarbejde med virksomheden CLC bio, da dette gav os mulighed for at anvende deres framework samt ekspertise. Herudover vil vores implementering indgå i deres analyseværktøj CLC Workbench. Eftersom alignment af genomer er første skridt i en række af analyser, er det naturligt at lade vores genomaligner blive integreret med CLC Workbench, som netop tilbyder en lang række af efterfølgende analyser. Selve udviklingsforløbet er foregået i en iterativ proces, hvor vi er endt ud med tre versioner, der delvist bygger oven på hinanden: Første version har selve forståelsen af Mauves algoritme, samt de udfordringer der ligger i en implementering heraf, som sit omdrejningspunkt. Anden version omhandler implementeringen af en fuld funktionel udgave af en genomaligner, der har medtaget alle dele af Mauves algoritme og ydermere er implementeret ved brug af CLC bio s framework. Sidste version består af en videreudvikling af algoritmen, baseret på andre artikler og observationer gjort undervejs i udviklingsforløbet. Undervejs og efter hver udviklingsiteration sammenholdes vores resultat med Mauve og relaterede programmer, både ved hjælp af alignment af reelle genomer, samt alignment af simulerede genomer, genereret ud fra vores egen sekvenssimulator. Vi har valgt at lave en sekvenssimulator, for at kunne perspektivere resultaterne hørende til de reelle data, samt at få indblik i hvor høj grad algoritmerne kan spore simulerede, evolutionære events. Dette speciale starter med, at vi i kapitel 2 gennemgår udvalgte dele af den klassiske teori og algoritmer for evolution og alignments. På baggrund af den introducerede teori gennemgår kapitlerne 3, 4 og 5 de tre versioner af vore implementering. Disse versioner er kaldt henholdsvis Prototype, Draft og Final og er struktureret som vores udviklingsforløb, hvor hver version tilføjer funktionalitet og optimeringer. Kapital 6 indeholder resultater for vores endelige udgave, hvor vi sammenligner vores implementering med lignende programmer. Til sidst evaluerer vi i kapitel 7 vores udviklingsproces og opnåede resultater. 1 Mauve 1.2 er den version der svarer til algoritmen der beskrives i Mauveartiklen. Mauve 1.2 kan hentes via

8 K A P I T E L 2 EVOLUTION OG ALIGNMENTS Som det fremgår af indledningen er der flere årsager til hvorfor man ønsker at sammenligne hele genomer. En udbredt metode til at fortage en sammenligning er, at benytte en såkaldt alignment, der kan identificere konseverede områder. Mere præcist, så er det biologiske formål med at aligne sekvenser at matche de nukleotider eller aminosyrer, der eksempelvis kunne være homologe med hinanden. Det at områder mellem sekvenser er homologe betyder at de har fælles evolutionær oprindelse. En traditionel alignment giver mulighed for at se forskelle mellem sekvenserne, som kan være forårsaget af small-scale-events og gør det lettere at lave analyser på de områder af sekvenserne, der er homologe [17, kapitel 3 og 5]. Vi vil i dette kapital gennemgå og uddybe de teoretiske forudsætninger for at forstå de forskellige typer af evolutionære events, der gør det ikke-trivielt at lave en alignment. Efterfølgende vil vi kigge på en række af algoritmer, der givet forskellige antagelser om events, foretager en alignment. 2.1 Evolution af genomet Gennem tiden har organismer udviklet og ændret sig [19]. Disse forskelle er opstået gennem ændringer af organismernes dna, der så er blevet videreført gennem generationer. Disse ændringer kan ske på mange forskellige måder: som fejl i kopiering af dna, som følge af radioaktiv bestråling, påvirkning af et virus samt nedbrydning forårsaget af det livsvigtige ilt. Alle disse elementer kan beskadige de enkelte nukleotider der udgør dna et. Resultatet af dette er som oftest såkaldte Single Nucleotids Polymorphism (SNP), hvor en enkelt nukleotid har ændret sig fra fx Adenine 3

9 4 KAPITEL 2. EVOLUTION OG ALIGNMENTS Figur 2.1: Skitse af to tilfælde der kan give anledning til ændring af kromosomstrukturen. Det første omhandler hvordan et kromosompar kan ændre strukturen indenfor kromosomet. Sidste tilfælde illustrerer hvordan dna kan udveksles mellem to forskellige kromosomer. Figuren er lånt fra [8]. (forkortet A) til Tyrosine (forkortet T). Der kan også forekomme andre typer af begivenheder, hvor nye nukleotider bliver sat ind eller fjernet. Disse typer af ændringer i dna et kategoriseres som small-scale-events da de netop er mindre lokale ændringer hvor det foregående og efterfølgende dna stadig er uændret. Genomer undergår også en anden type af begivenheder, som betegnes largescale-events og omfatter flytning af et stykke af dna et fra et sted i genomet til et andet (rearrangement), men kan også omfatte at et segment bliver vendt om (inversion). Det at et segment bliver vendt om, betyder at læseretningen er modsat, samtidigt med at det er komplementet der læses. Dette betegnes som at segmentet ligger i reverse-komplementet. Disse large-scale-events kan give anledning til en drastisk ændring af genomet. For at en large-scale-event kan opstå, skal en række af betingelser være opfyldt samtidigt. Nedenfor er vist en række af de begivenheder der kan give anledning til at et rearrangement opstår: To ellere flere kromosomer skal knække over samtidigt. Reparationsmekanismerne i cellen forsøger at binde de knækkede kromosomer sammen ved at forbinde enderne. Hvis enderne forbindes rigtigt er begge kromosomer som før, og der opstår altså ingen rearrangements. Hvis enderne derimod forbindes forkert kan der opstå et kromosom-rearrangement. Det kræver dog yderligere at begge kromosomer skal have netop én centromer, da den efterfølgende celles replikering ellers ikke vil medtage de ændrede kromosomer. En skitse over denne type af large-scale-events kan ses på figur 2.1.

10 2.2. ALIGNMENT AF SEKVENSER 5 I de fleste tilfælde vil både large- og small-scale-events give anledning til flere genetiske defekter for et individ og derved gøre det mindre sandsynligt, at ændringen bliver udbredt i de efterfølgende generationer af arten. I tilfælde hvor få individer af en art er isoleret fra andre artsfæller, kan tilfældigheder spille ind og være årsag til at tilfældig genetisk drift gør ændringen udbredt efter blot nogle få generationer. Desuden kan der opstå ydre faktorer som favoriserer ændringen og derved leder til dens udbredelse. Efter lang tids adskillelse af arter kan der opstå så mange ændringer i hver af disse, at de ikke længere kan få fertilt afkom og der er givet anledning til en ny art. Overstående diskussion viser eksempler på, at når man betragter dna et for hele genomer vil der være forskelle i form af både large-scale- og small-scale-events. I de næste fire afsnit kigges der nærmere på hvordan alignment af sekvenser foregår og hvordan man tager højde for small-scale events. Efterfølgende vises hvordan man kan udvide alignments til også at omfatte large-scale-events. 2.2 Alignment af sekvenser Et af de mest fundementale og alligevel hyppigst anvendte værktøjer til analyse af dna- og proteinsekvenser er en alignment. En alignment er en sammenligning mellem to eller flere sekvenser hvor hver homolog nukleotid forsøges opstillet i søjler. For hver søjle i en alignment er der tre tilfælde: En matchende søjle hvor alle nukleotider er ens, svarende til at ingen mutationer er sket. En substitutionssøjle hvor en nukleotid i mindst en sekvens er forskellig fra de øvrige, svarende til at der er sket en mutation i en eller flere af sekvenserne. En insertion-/deletion-søjle hvor en eller flere sekvenser har en nukleotid der er gået tabt eller blevet indsat. Dette betegner et gap og repræsenteres ved -. En alignment kan tildeles en score ud fra en score-funktion, score-matrix og gap-cost. En score-matrix angiver scoren at en matchende søjle og en specifik substitutionsøjle, mens gap-cost angiver hvad der skal trækkes fra scoren når et gap observeres. En score-funktion bruger score-matricen og gap-cost til at lave en samlet score, hvor der dog også kan tilføjes yderligere hensyn til udregningen af scoren. Figur 2.2 viser et eksempel på udregningen af scoren for en alignment. En optimal alignment er den alignment med den størst mulige score for en given score-funktion, score-matrix og gap-cost. Der kan være mere end én optimal alignment. De metoder der kun betragter to sekvenser betegnes som parvise alignment-metoder, hvor dem der kigger på mere end to sekvenser betegnes som multiple alignments-metoder.

11 6 KAPITEL 2. EVOLUTION OG ALIGNMENTS Alignment: S: ACCTG---GCGG T: AC--GCGGGCTG Score: =10 Score-matrix: A C T G A C T G Gap-cost: 3 Figur 2.2: Et eksempel på tildeling af en score til en global alignment ud fra en scorematrix og gap-cost. Alignment: CTAACTGACGTAC ---ACTGATG--- Global alignment score: =7 Lokal alignment score: =25 Figur 2.3: Illustration af forskellen på scoren for en lokal og global alignment, baseret på score-matricen fra figur 2.2. En alignment kan være global eller lokal. Globale alignments er hvor man forsøger at matche samtlige nukleotider i begge sekvenser. I lokale alignments tillader man derimod, at der kun er dele der matcher mellem sekvenserne. For lokale alignments kan scoren således ikke blive negativ, trods at der er mange gaps i træk. Et eksempel kan ses af figur 2.3, hvor score-matrix og gap-cost er som ved det tidligere eksempel. Lokale alignments er en fordel hvis sekvenserne har forskellig størrelse og kan desuden også være en fordel for meget divergente sekvenser, hvor det ikke giver mening at aligne alle nukleotiderne mod hinanden [17, side 87]. Efter at have introduceret globale og lokale alignments, gennemgås i næste afsnit de algoritmiske problemstillinger der opstår ved bestemmelse af optimale alignments og hvordan disse kan løses. 2.3 Algoritmer for parvis alignment En af de tidligste algoritmer til at lave en alignment mellem to sekvenser er Needleman-Wunch-algoritmen [18]. Denne algoritme foretager som udgangspunkt en global alignment, men kan let modificeres til at håndtere en lokal alignment. Algoritmen danner grundlag for mange af de alignmentmetoder der bruges i dag. Needleman-Wunch er en dynamisk algoritme, der udfylder en todimensional

12 2.4. ALGORITMER FOR MULTIPLE ALIGNMENT 7 tabel, jævnfør rekursionsudtryk 2.1. I dette udtryk er cost en funktion der angiver hvor godt to tegn matcher og gapcost er en parameter for prisen for insertions og deletions. Indgang (i, j ) i den tilhørende tabel angiver scoren for en alignment mellem delsekvenserne S[1..i ] og T [1..j ] hvor S og T er de to sekvenser der skal alignes. Den optimale alignment kan findes ved at lave backtracking i tabellen efter den er udfyldt. score(i, j )=max 0 for i = 0, j = 0 score(i 1, j 1)+cost(S[i ],T [j ]) for i > 0, j > 0 score(i 1, j )+gapcost for i > 0 score(i, j 1)+gapcost for j > 0 (2.1) Det er værd at bemærke at Needleman-Wunch beregner en optimal alignment. Hvis begge sekvenser har længde n og hver tabelindgang kan udfyldes i O(1) tid, er den samlede udførelsestid for algoritmen O(n 2 ), hvilket kommer alene af antallet af indgange i tabellen der skal udfyldes. Pladsforbruget er ligeledes O(n 2 ). Smith-Waterman er en modificeret udgave af Needleman-Wunch-algoritmen der tillader lokale alignments [21]. Den primære forskel i Smith-Waterman er at negative indgange sættes til nul, hvilket konceptuelt svarer til at en ny alignment påbegyndes. Desuden sættes første række og søjle i tabellen fra Needleman-Wunchalgoritmen til nul. Det er for Smith-Waterman påkrævet at gap cost er negativ. Disse ændringer giver anledning til følgende ændrede rekursionsudtryk 2.2. score(i, j )=max 0 for i = 0 j = 0 score(i 1, j 1)+cost(S[i ],T [j ]) for i > 0, j > 0 score(i 1, j )+gapcost for i > 0, j > 0 score(i, j 1)+gapcost for i > 0, j > 0 (2.2) Smith-Waterman har samme asymptotiske udførelsestid og pladsforbrug som Needleman-Wunch, da tabellen der udfyldes har samme størrelse. 2.4 Algoritmer for multiple alignment Det er ofte interessant at betragte mere end to sekvenser af gangen. Dette kan opnås ved at lave en udbygning af den eksisterende bestemmelse af scoren, så den kan håndtere flere sekvenser. En simpel udvidelse er SP-scoren, hvor SP står for sumof-pairs. Ved SP-scoren scores hvert par i en multiple alignment med hinanden, som var det en parvis alignment. SP-scoren for en multiple alignment M, med k

13 8 KAPITEL 2. EVOLUTION OG ALIGNMENTS sekvenser af længde l, kan formuleres således: SP(M)= 1 i<j k = 1 i<j k = 1 c l = 1 c l score(r i,r j ) (2.3) 1 c l 1 i<j k SP M 1c. M kc d(r i [c],r j [c]) (2.4) d(m i c, M j c ) (2.5) (2.6) hvor R i er række nr. i i M og d(a,b) er en kombination af cost og gap-cost fra tidligere, mellem to nukleotider a og b. Omskrivning viser at SP-scoren kan forstås som en kolonnescore hvor hver kolonne i en multiple alignment M scores uafhængigt. Det er svært at tillægge SP-scoren nogen teoretisk retfærdiggørelse, ud over at den er nem at arbejde med [11]. Needleman-Wunch-algoritmen kan udvides til at finde en optimal alignment for k sekvenser ved brug af SP-scoren. Dette gøres ved at udvide tabellen til k dimensioner og udfylde tabellen ved for hver indgang at se på alle omkringliggende indgange og ellers følge rekursionsudtrykket fra før. Såfremt alle sekvenser har længde n, bliver udførelsestiden og pladsforbruget nu O(n k ). Dette udtryk vokser eksponentielt da k er antallet af sekvenser. I praksis er denne algoritme ikke anvendelig, hvilket kan ses ud fra følgende regnestykke af den tid det vil tage at lave en alignment af tre bakterielle genomer, hver af en længde på 5 mio. nukleotider. Hvis det antages at der kan foretages 10 mia. regneoperationer per sekund 1, vil det tage ( ) 3 op op/s = 1, s 396 år. Det kan vises, at en optimal løsning for multiple alignment baseret på SP-scoren er et NP-komplet problem [14], hvorfor det ikke er sandsynligt at man kan lave en asymptotisk hurtigere algoritme end den udvidede Needleman-Wunch. Der findes dog en algoritme, nemlig MSA [10], der i praksis kan spare tid og plads ved at se bort fra kombinationer, der ikke kan give anledning til en optimal alignment. I næste afsnit kigges der på hvordan algoritmer for alignment af flere sekvenser kan gøres hurtigere ved at gå på kompromis med kravet om at finde en optimal alignment. 1 Estimat baseret på

14 2.5. HEURISTISK MULTIPLE ALIGNMENT Heuristisk multiple alignment For at få en praktisk, anvendelig udførelsestid, bruges forskellige heuristiske tiltag. Med praktisk anvendelig menes der hvad der kan håndteres af en almindelig workstation inden for en tid der kunne være nogle timer eller dage. Ved heuristiske tilag nøjes man med at lede efter en god alignment fremfor at finde en optimal alignment. Progressive alignment er en heuristik der ofte er brugt som basis for konstruktion af multiple alignment. I en progressive alignment laves parvis alignment mellem alle par af sekvenser og resultatet bruges til at konstruere en fælles multiple alignment ud fra et såkaldt guide tree. Et guide tree er et træ over hvilke arter / sekvenser der er mest beslægtede, og kan bruges som guide til at kombinere parvise alignments til en multiple alignment. Dette tager O(kn 2 ) tid (hvor k er antallet af sekvenser) og O(n 2 ) plads. Hvis der kigges på samme scenarie som i forrige afsnit hvor tre bakterielle genomer skulle alignes, så tager det nu: 3 (5 106 ) 2 op = 125 min op/s Selvom dette ikke nødvendigvis er den eksakte udførelsestid, så fortæller det, at det nu er blevet praktisk muligt at aligne disse 3 genomer. Der er dog visse problemer med det kvadratiske pladsforbrug, men der findes optimeringer der kan bringe dette ned på eksempelvis lineær plads, ved kun at huske to rækker og så genberegne når nødvendigt. Dette kan dog give anledning til at udførelsestiden øges med en konstant. Et eksempel på en progressive algoritme, er det udbredte multiple alignment værktøj Clustal W [22]. Problemet ved at bruge et enkelt guide tree er at det i nogen sammenhænge giver anledning til en alignment der har plads til forbedringer. Det er muligt at bruge en iterativ proces, hvor man først følger samme fremgangsmåde som beskrevet før og herefter prøver at aligne delmængder af sekvenserne for at finde lokale forbedringer. Dette giver endvidere mulighed for en afvejning mellem tid og alignment-kvalitet. Der er adskillige problematikker ved progressive metoder. De skalerer stadig ikke godt til meget store sekvenser, så som hele kromosomer eller genomer der kunne være af en længde på mellem flere millioner til milliarder af nukleotider, da hver parvis alignment bruger O(n 2 ) tid og kræver O(n 2 ) plads. Der er mange metoder som forsøger at muliggøre alignment af store sekvenser [3]. Disse metoder antager ofte at sekvenserne er kolineære, hvilket vil sige der ikke er foregået large-scale-events og dermed at konserverede områder kommer i samme rækkefølge. Af eksempler på metoder kan nævnes Muscle [7] og Mummer [13]. En grundlæggende ide bag ikke bare disse to, men også ifølge en artikel der gennemgår et større udvalg af metoder [3], den som kommer fra en artikel af Dumas fra 1982 [6]. Ideen består i at finde eksakte matches af en fast længde mellem sekvenser, kaldet k-mers. Disse k-mers inspiceres efterfølgende for om de er en del af en større fælles delsekvens. Endeligt kan flere af disse matchende delsekvenser

15 10 KAPITEL 2. EVOLUTION OG ALIGNMENTS grupperes med tilladelse af visse variationer mellem dem. Den nævnte metode, Mummer, er værd kort at kigge nærmere på, da den benytter et såkaldt suffix træ. Denne datastruktur muliggør identifikation af fælles suffikser og er en klassisk og velstuderet datastruktur inden for området af strengalgoritmer. Identifikation af suffikser er her interessant fordi det kan benyttes til effektivt at finde fælles k-mers. Ulempen er dog et højt pladsforbrug og derfor er fremgangsmåden ikke altid en oplagt mulighed. Indtil nu har vi kun betragtet algoritmer der kan håndtere small-scale-events. Ved analyse af hele kromosomer og genomer bliver det nødvendigt at tage largescale-events i betragtning, for at få en meningsfyldt alignment. Derfor vil vi i næste afsnit kigge nærmere på hvordan netop large-scale-events kan håndteres. Det skal bemærkes at flere af de teknikker, der er blevet kigget på til håndtering af smallscale-events kan genbruges. 2.6 Multiple alignment med large-scale-events Dette afsnit vil kigge nærmere på tre metoder, der alle kan håndtere large-scaleevents, kaldet Mauve [5], Progressive Mauve [4, kapitel 5] og Shuffle-LAGAN [2]. Disse er interessante da det er tre tilgangsvinkler til at foretage alignment af hele genomer og vi vil derfor kunne lade os inspirere af teknikker fra hver enkelt, samt lave sammenligner af resultater. Inden der kigges nærmere på de enkelte metoder, er det værd at se hvilke fællestræk disse metoder har både med hinanden og med tidligere nævnte alignment-metoder. Den grundlæggende fremgangsmåde er nemlig den samme: 1. Identifikation af fælles delsekvenser. 2. Gruppering af fælles delsekvenser. 3. Alignment af sekvenerne baseret på de fundne grupperinger, eventuelt med inddragelse af metoder for traditionel heuristisk multiple alignment. I de næste afsnit vil vi forsøge at forklare hver af ovenstående nævnte metoder ud fra disse tre trin Mauve Programmet Mauve [5] forsøger at håndtere nogle af de problemer som fremgår af de forrige afsnit. Dette muliggør sammenligning af hele genomer. Resultatet af en sammenligning i Mauve er en række små, lokale multiple alignments som betegnes Local Collinear Blocks (LCB er). Ideen med hver LCB er at de udgør en homolog delsekvens (fælles evolutionær oprindelse), som er kolineær i

16 2.6. MULTIPLE ALIGNMENT MED LARGE-SCALE-EVENTS 11 Figur 2.4: Eksempel på to sekvenser hvor der er fundet to homologe områder, betegnet LCB 1 og LCB 2. Placeringen af LCB 2 i Sek 2 betyder at læseretningen ligger i reverse-komplementet. hver sekvens. Her betyder kolineær at delsekvenserne har samme læseretning. Eftersom LCB er er kolineære, kan hver LCB betragtes som en traditionel multiple alignment. Figur 2.4 viser en simpel illustration af LCB-begrebet. Mauve består af følgende trin, som der vil blive kigget på i større detaljegrad, i de efterfølgende underafsnit: Find homologe ankre mellem sekvenser under analyse. Udvid ankre til maksimale lokale alignments. Beregn guide tree. Find delmængder af lokale alignments der udgør LCB er. Raffiner LCB er iterativt. Brug af en traditionel heuristisk multiple alignment-metode til at lave alignments de steder i LCB er, hvor der er et mellemrum mellem de lokale alignments. Sammenlignes ovenstående punkter med de tre grundlæggende trin identificeret i starten af afsnit 2.6, så svare de første tre punkter omtrent til identifikation af fælles delsekvenser. De næste to punkter omhandler grupperingen af fælles delsekvenser. Det sidste punkt svarer til alignment af sekvenserne, baseret på de fundne grupperinger. Inden der kigges på detaljerne for hvert trin, som Mauve består af, kan der kigges på figur 2.5 for en illustration over de væsentligste trin i mauve, svarende til punkt nr 1, 2 og 4 i ovenstående liste. Identifikation af homologe ankre Mauvealgoritmen forsøger i dette trin at finde små, fælles delsekvenser som kan bruges i de efterfølgende trin. Dette afsnit samt det efterfølgende betegnes i Mauve-

17 12 KAPITEL 2. EVOLUTION OG ALIGNMENTS ' 1 +, +,)* GCCAATATGAGCGTCGGGTTTGATGTGCTCGGGGCGGCGGTGGCACC... CCAATATGAGCAGGAGCTTGGGTGATGTGCTCGGGGCGGCGGTGGCACAGTGGCGAC... CGCAATATGAGCGTCGGGTTTGATGTGCTAGCGAGCGGGCGGCGGTGGCACC... -.))* + +,, GCCA CCAA CAAT AATA...! CCAA CAAT AATA ATAT... CGCA GCAA CAAT AATA... '()* + +,, AACC AATA ACAC AGGT...! AAAC AAAT AATA AGGT... AAAA AACA AACA AACG... /,)))* + ) 0) 1 *,23 + ((,)( +,, 4 EFGH EFGH EFGH '+()1)*( *,23 +,)( )1())+() + 5 4),( 01*2 ( + EFGH EFGH EFGH 6 01)1 7,8* 4 9 :0,(+(( 8 ;+)+, <) ;+(=4 >;<;?@5 4 (0,,,+. (), )1( A "#"& "#"& "#"$ "#"% "#"& "#" "#" "#" "#" I,)8 ;<;? *0.. ) JKL? BCD& BCD$ "#"$ "#"% "#"& BCD$ "#" BCD$ "#"& BCD& "#" "#" BCD& "#"$ "#"% Figur 2.5: Overordnet gennemgang af de første væsentlige trin Mauve består af.

18 2.6. MULTIPLE ALIGNMENT MED LARGE-SCALE-EVENTS 13 artiklen som seed-and-extend. Mauve leder i første omgang efter k-mers der forekommer i alle sekvenser med en fast længde k. Når der findes en k-mer der forekommer i alle sekvenser haves der hvad vi betegner som et anker. Mauve kræver at k-mers skal være unikke i hver sekvens. Dette gør at de fundne k-mers er gode til at identificere homologe ankre, idet ankret repræsenterer et bevaret område, der forekommer netop én gang i hver sekvens. Såfremt det ikke var et krav at k-mers skulle være unikke, ville det være svært at vide hvilke k-mers der repræsenterede den samme delsekvens i hver sekvens. Hvis der er r gentagelser af en k-mer i hver sekvens og der er G sekvenser, ville der være r G kombinationsmuligheder mellem de forskellige k-mers, hvilket vil give større usikkerhed og længere udførelsestid når homologe områder forsøges at identificeres. Ulempen ved at kræve unikke ankre er, at man muligvis ser bort fra ankre der kun er bevaret i en delmængde af sekvenserne samt at repeats giver anledning til steder hvor man ikke umiddelbart kan finde k-mers som udgør et anker. Repeats er områder hvor den samme delsekvens har flere forekomster. Det sidste problem bliver dog i højere grad løst senere i algoritmen. Således giver Mauves valg af ankre et sikkert, men lidt begrænset grundlag at bygge videre på. Mauve har valgt en metode til at finde ankre, hvor først alle mulige k-mers listes og efterfølgende sorteres leksikografisk. Her inkluderer alle k-mers også dem for reverse-komplementet, dvs. begge læseretninger. Det at de listede k-mers er sorteret, muliggør hurtig identifikation af ikke-unikke k-mers, samt sammenligning med k-mers fra andre sekvenser med henblik på hvilke der forekommer i to eller flere. Resultatet af dette trin er en sorteret liste af k-mers uden dubletter for hver sekvens. Konstruktion af maksimale lokale alignments Næste skridt benytter listerne af sorterede k-mers til at finde, hvad der svare til lokale multiple alignments der matcher eksakt. Disse alignments betegnes Maksimale Unikke Matches (MUM s) og defineres formelt som en tupel L,S 1,S 2,...,S G, hvor L er længden og S 1,S 2,...,S G er positionen i hver sekvens. MUM s findes ved at gennemløbe de sorterede lister af k-mers og identificere dem, som forekommer i alle sekvenser. Når en række af ens k-mers er fundet, undersøges det om disse kan udvides til at matcher yderligere nukleotider i hver sekvens, og efterfølgende udgør disse så en MUM. Flere ankre kan give anledning til samme MUM og behøves derfor ikke at betragtes igen. Frem for at sammenligne hver kandidat med alle tidligere, opererer Mauve med et begreb kaldet generaliseret offset til at identificere ankre som fører til MUM s der allerede er fundet. Generaliseret offset er defineret ved funktion 2.7 hvor M er det pågældende anker og M.S j offset for den j te k-mer i ankeret. Funk-

19 14 KAPITEL 2. EVOLUTION OG ALIGNMENTS tion 2.7 benyttes som hashfunktion til at nedbringe antallet af MUM s der skal sammenlignes med, idet der nu kun sammenlignes med MUM s der har samme relative offset. G h(m)= M.S j M.S 1 (2.7) j=1 Intuitionen bag det generaliserede offset er, at et anker som er indeholdt i en allerede eksisterende MUM, vil have det samme relative offset internt i den pågældende MUM. I tilfælde af at mange MUM s hasher til den samme værdi, benytter Mauve yderligere et binært søgetræ for hver indgang i deres hashtabel for eksisterende MUM s. Næste fase i Mauve forsimples ved til sidst at fjerne eventuelle overlaps mellem MUM s. Dette gøres forinden ved at afkorte den korteste MUM når de betragtes parvist. Guide tree og gruppering af MUM s Mauve opbygger under ankersøgningen et guide tree der i sidste fase kan bruges som input til Clustal W-algoritmen, hvis funktion er at foretage alignment af regioner mellem MUM s. Undervejs i Mauves søgning efter MUM s findes en del med en såkaldt multiplicitet der er mindre end antallet af genomer. Begrebet multiplicitet er antallet af sekvenser, som den pågældende MUM strækker sig over. Mauve gemmer denne information om hvor meget sekvenserne parvist har tilfælles. Ud fra denne information kan en afstandsmatrix laves, der angiver hvor beslægtede de forskellige genomer er. En algoritme som f.eks. neighbour-joining [20] bruges herefter til at generere et guide tree ud fra afstandsmatrixen. Beregning af LCB er er det næste trin i Mauve hvilket sker ved at gruppere MUM s. Dette gør de med udgangspunkt i en definition af et breakpoint fra [1]. Et breakpoint er her når to MUM s i en sekvens ikke har samme ordning. Derfor defineres en LCB som en delmængde af MUM s, her betegnet M, der har en total ordning M i.s j M i+1.s j for alle M i i M og 1 j G. Af [1] kan bemærkes at det at finde en optimal grupering af MUM s via breakpoints bygger på en løsningen til Travelling Salesman Problemet, hvilket gør en optimal algoritme tidsmæssig urealistisk at anvende. Af denne grund har Mauve valgt en approksimativ grådig algoritme i stedet for. Forinden fjerner Mauve alle MUM s med multiplicitet lavere end antallet af genomer da der ikke tages højde for disse i den grådige algoritme. Overordnet inddeles MUM s i LCB er som efterfølgende forsøges optimeret ved at fjerne de mindste LCB er, for derefter at gentage algoritmen. Denne gruppering betegnes af Mauveartiklen [5] som greedy breakpoint elimination og starter med at nummerere hver MUM fortløbende efter rækkefølgen de forekommer i, i første sekvens, hvilket Mauveartiklen betegner M i.label. For at finde breakpoints sorteres listen af MUM s efter forekomsten i hver af de øvrige se-

20 2.6. MULTIPLE ALIGNMENT MED LARGE-SCALE-EVENTS 15 Før Greedy Breakpoint Elimination MNOP YZ[T YZ[U YZ[V YZ[W RSRT RSRU RSRV RSRW RSRX MNOQ YZ[T YZ[U RSRT YZ[V RSRU RSRV RSRW Efter Greedy Breakpoint Elimination YZ[W RSRX \]^_ ghic ghid abac abad abae abaf \]^` ghic aba c abad abae ghid abaf Figur 2.6: Den første figur viser to sekvenser hvor hver MUM, illustreret ved en kasse der forekommer i begge sekvenser, tilhører en LCB. LCB 2 består af to MUM s på den første figur. Den anden figur viser hvordan situationen kunne være efter en iteration af Greedy Breakpoint Elimination algoritmen hvor LCB 3 er fjernet og der haves nu en LCB bestående af tre MUM s. kvenser, en af gangen hvor listen inspiceres for breakpoints. En af følgende betingelser skal være sande for at der ikke findes et breakpoint mellem to MUM s, M i og M i+1 : Hvis M i.label+1= M i+1.label samt M i og M i+1 ligger i forward-retningen Hvis M i.label 1= M i+1.label samt M i og M i+1 ligger i reverse-retningen Følgende eksempel viser hvordan rækkefølgen af M i.label kunne se ud. Nummering af MUM s efter ordning i den første sekvens Sortering af MUM s efter ordning i den anden sekvens Ovenstående vil give anledning til breakpoints mellem 2 og 3, 3 og 4 samt 4 og 5. Disse breakpoints giver anledning til følgende LCB er: LCB 1 = {1,2}, LCB 2 = {3}, LCB 3 = {4} og LCB 4 = {5,6}. Næste skridt er grådig udvælgelse af de største LCB er. Konkret så findes først en vægt af hver LCB, hvilket Mauve fastsætter til længden af de MUM s den udgøres af. En eller flere LCB er vil så have den laveste vægt som fjernes, hvilket gøres ved at fjerne de MUM s som udgjorde netop disse LCB er. Et eksempel på dette fremgår af figur 2.6. Såfremt ikke alle LCB er nu har opnået en ønsket minimumsvægt, gentages ovenstående, hvorved yderligere MUM s fjernes.

21 16 KAPITEL 2. EVOLUTION OG ALIGNMENTS Iterativ ankersøgning: Intern og ekstern ankersøgning I et forsøg på at forbedre kvaliteten af de fundne LCB er eller finde yderligere LCB er, anvendes samme algoritme iterativt. Fælles for intern og ekstern ankersøgning er at de justerer størrelsen af k-mers for det de betrager. Dette gøres efter formel 2.8, hvor S = (S 1,S 2,...,S G ) er de delsekvenser der søges i. Denne tilpasning af k-mer størrelsen medfører at følsomheden forøges når der søges i mindre delsekvenser. Den bagvedliggende ide er, at en del af disse mindre k-mers, som tidligere ikke var unikke, nu på en mindre sekvens kan bidrage med nye ankre. Formlen er ifølge Mauveartiklen [5] udledt ved emperiske forsøg. ( ) G length(s j ) seed_size(s)=log 2 (2.8) j=1 G Intern ankersøgning kan forbedre LCB er, ved at lede efter yderligere MUM s mellem de eksisterende MUM s i hver LCB. Disse ekstra MUM s efterlader mindre områder internt i LCB erne, som skal håndteres til slut. Mindre områder betyder at det bliver hurtigere at aligne disse samt giver en mindre risiko for en fejlagtig alignment, forudsat at der haves tillid til de MUM s, der blev fundet. Ud over en forbedring af udførselstiden, kan disse ekstra MUM s også bevirke at områder der ellers måtte opgives, da de var for tidskrævende at aligne med en traditionel heuristisk multiple alignment metode, nu kan alignes. Idet at MUM s i en LCB alle har samme orientering for hver sekvens, skal der for hver sekvens kun søges efter k-mers i den pågældende orientering. Søgte man i begge orienteringer, ville det kunne give anledning til en opsplitning af LCB en. I praksis anvender Mauve en minimumsgrænse på 200 nukleotider for hvor små mellemrum der skal undersøges for ekstra MUM s. Ekstern ankersøgning bruges til at finde flere LCB er eller udvide de eksisternde. Dette gøres ved at konkatenere alle delsekvenserne mellem de eksisterende LCB er. Mauve benytter en k-mer størrelse på seed_size(s) 2 når der iterativt kigges på de konstruerede sekvenser. De fundne MUM s oversættes tilbage til de oprindelige sekvenser, hvilket kan betyde at visse k-mers opsplittes, såfremt de spænder over flere konkatenerede delsekvenser. Resultatet bliver et antal nye MUM s som kan tilføjes til de eksisterende MUM s. Herefter genberegnes alle LCB er. Så længe den samlede vægt af alle LCB er forøges, gentages søgningen. Altså indtil, den grådige eliminering af LCB er enten fjerner alle de nye LCB er eller der slet ikke opståer nogle nye LCB er. Når LCB erne er optimeret i det omfang det er muligt, benyttes Clustal W til at lave en progressiv multiple alignment, idet der netop haves en række af mindre delsekvenser med samme orientering. Det er kun nødvendigt at lave denne multiple alignment på områderne internt i hver LCB mellem MUM s, idet MUM s allerede

22 2.6. MULTIPLE ALIGNMENT MED LARGE-SCALE-EVENTS 17 tuvwxvy z{ }v}~ } klkm klkq j n n o j o o n j p p o p p n p j o j p o p n p n n ƒ} }v } z{ }v}~ } klkr klks Figur 2.7: Denne figur viser et eksempel, hvor fire MUM s overlapper hinanden i én sekvens. De fire nukletoder der er markeret med orange indgår i samtlige fire MUM s. Grundet måden MUM s bliver dannet på, kan de ikke overlappe fuldstændig matcher eksakt. Bemærk at det tidligere beregnede guide tree også kan gives som input til Clustal W for at øge hastighed og kvalitet. Udførelsestid for Mauve Det der dominerer udførselstiden for Mauve, er identifikation af homologe ankre og konstruktion af MUM s. Derfor gennemgås udførselstid for disse to faser overordnet. For identifikation af homologe ankre sorteres der en k-mer liste for hver af G sekvenser. Sorteringen af listerne med k-mers gøres med radix sort, hvilket giver en udførelsestid på O(Gn) for dette trin, hvor G er antal genomer og n er længden af hver af disse. Angående udførelsestiden for konstruktion af MUM s, så blev der brugt en hashfunktion betegnet et generaliseret offset. Da der kan være op til Gn/2 MUM s, benyttede Mauve et binært søgetræ for hver indgang i hashtabellen for at sikre en udførelsestid på O(Gn log(gn)) skulle alle MUM s hashe til den samme indgang. En sidste faktor der påvirker udførelsestiden for at finde MUM s, er den størrelse ankre bliver udvidet med, for at udgøre en MUM. Hver nukleotid i en sekvens kan højest være indeholdt i fire MUM s, hvilket fremgår af Mauveartiklen [5] og illustreret af figur 2.7. MUM s med lavere multiplicitet kan indeholde de samme delsekvenser som udgør MUM s med højere multiplictet og derfor kan hver nukleotid i en sekvens være en del af 4G MUM s. Dette betyder at antallet af sammenligninger, en nukleotid kan være involveret i, er 4G og da der haves Gn nukleotider, er det maksimale antal sammenligninger 4G Gn. Den samlede udførelsestid for at finde MUM s er ifølge Mauveartiklen O(Gn log(gn)+g 2 n), hvilket stemmer overens med betragtningerne gennem dette afsnit.

23 18 KAPITEL 2. EVOLUTION OG ALIGNMENTS Opsummering af Mauve Mauve håndterer large-scale-events og muliggører alignment af hele genomer, men der er stadig muligheder for optimeringer af hastighed og kvalitet. Det at der kræves, at en k-mer skal indgå i samtlige sekvenser, for at den kan udgøre en MUM, kan blive en begrænsning, såfremt mange divergente sekvenser analyseres samtidigt. Der tages også udgangspunkt i eksakte matches hvilket kan gøre det svært at finde ankre i organismer, som enten er fjernt beslægtet eller har en høj mutationsrate. Disse forhindringer forsøger metoden i næste afsnit at tage hånd om, ved at videreudvikle ideen bag Mauve. Siden udgivelsen af Mauveartiklen i 2004 er der sket en videreudvikling af implementeringen. Den implementering der svarer til Mauveartiklen er Mauve 1.2, hvor den seneste frigivne udgave er Mauve 2.3. Vi vil i dette speciale indledningsvis sammenligne os med Mauve 1.2, men vil dog inddrage Mauve 2.3 i kapitel 6, hvor vi sammenligner os med andre whole genome alignment værktøjer Progressive Mauve Progressive Mauve er en videreudvikling af Mauve, der gennem en række ekstra hensyn forsøger at forbedre kvaliteten af en såkaldt multiple genome alignment [4], som altså er en whole genome alignment metode, hvor målsætningen er at kunne aligne et større antal genomer uden at kvaliteten degraderes, som ved den almindelige Mauve. Dette skyldes at Progressive Mauve ikke har et krav om, at et anker skal være i alle sekvenser. Ved at anvende samme metode som Mauve, parvist på sekvenserne, får man også de bevarede områder, der kun er bevaret mellem nogle af sekvenserne. Dette gør Progressive Mauve bedre til at sammenligne sekvenser hvor frekvensen af evolutionære begivenheder ikke er den samme mellem alle de involverede sekvenser. Metoden tager udgangspunkt i Mauve, som beskrevet i afsnit De primære forskelle består i at betragte ankre der kun findes i en delmængde af sekvenserne. Dette gøres ved at betragte sekvenserne parvist og opbygge en multiple alignment, styret af et guide tree. Dette giver anledning til følgende fire grundlæggende trin der også vil blive beskrevet grundigere i de næste underafsnit. Parvis alignment mellem alle sekvenser jævnfør metoden beskrevet for Mauve. Udregning af to afstandsmatricer, som giver et estimat af antal breakpoints og ikke-homologe delsekvenser, for alle par af sekvenser. Et guide tree udregnes så efterfølgende på baggrund af afstandsmatricen for ikke-homologe sekvenser.

24 2.6. MULTIPLE ALIGNMENT MED LARGE-SCALE-EVENTS 19 Med udgangspunkt i hver knude i guide tree et, laves en progressiv alignment. Opbygningen af alignmentet styres af et afstandsmål. De tættest beslægtede alignments betragtes først. Når en række af LCB er er genereret, forsøges der iterativt at filtrere og forbedre disse. Parvis alignment Ideen med først at lave en række af parvise alignments, som hvis man bruger Mauve på to sekvenser ad gangen er, at det giver alle fælles delsekvenser mellem disse, fremfor kun de delsekvenser der eksisterer i alle sekvenserne. De delsekvenser der kun er i en delmængde af sekvenserne, forsøges efterfølgende inkluderet i den endelige alignment og kan også bruges som grundlag for opbygning af et guide tree på samme måde som beskrevet for Mauve i afsnit Yderligere giver det et grundlag for at opbygge afstandsmatricer, der ikke straffer large-scale-evolutionære begivenheder, på den måde en sammenligning på nukleotidniveau ville gøre. Ud fra afstandsmatricen kan et guide tree bygges. Set i forhold til Mauve, er der en anden stor forskel. Nemlig det at der kan håndteres ikke-eksakte k-mers. Dette betyder i praksis at en MUM kan indeholde enkelte mutationer i en eller flere af sekvenserne. Dette gør at der potentielt kan findes flere og større MUM s. Afstandsmatricer Der konstrueres to afstandsmatricer. Den første er et estimat for antallet af sikre breakpoints mellem alle par af sekvenser. Dette gøres ved at tage antallet af højtscorende LCB er. Det betyder at tilfældige matches får mindre indflydelse. Der kræves en høj score for LCB er, da det relative forhold mellem antallet af LCB er stadig er bevaret. Dette er baseret på emperiske observationer. Den anden afstandsmatrix estimerer mængden af ikke-homologe delsekvenser mellem alle par af sekvenser, hvilket består af de områder som ikke er indeholdt i en LCB. Progressive alignment Når den endelige multiple alignment skal opbygges gøres dette progressivt. Det tidligere udregnede guide tree angiver rækkefølgen for hvordan de allerede foretagede parvise alignments sammenlignes. Med udgangspunkt i de parvise alignments, opbygges multiple alignments der svare til interne knuder i guide tree et, for til sidst at have en multiple alignment der indeholder alle sekvenser. Hvilken knude der betragtes i guide tree et, vælges ud fra et afstandsmål mellem de to børn for den pågældende knude. Den multiple alignment for en given knude bestemmes ved at

25 20 KAPITEL 2. EVOLUTION OG ALIGNMENTS fjerne eventuelle overlap mellem MUM s, som i Mauve, mellem de to børn. Resultatet projiceres tilbage på hver af de alignments, som var grundlaget for den pågældende. Efterfølgende foretages der en gruppering af MUM s i LCB er. For disse LCB er udregnes en mere omfattende score i forhold til Mauve, der tager udgangspunkt i følgende udtryk. AnchorScore(M) = PairScore(M) Uniqueness(M) (2.9) I formel 2.9 er PairScore(M) en funktion for kvaliteten af en lokal alignment som benytter en scorematrix for substitutioner, kaldet HOXD. HOXD har den fordel at den er god til at skelne mellem homologe og urelaterede sekvenser. Uniqueness(M) er et udtryk for hvor unikt det tidligere fundet anker, startende i hver nukleotid, er i forhold til antallet af forekomster for netop dette anker globalt set i sekvenserne. Den endelige score for sammenligningen af to LCB er bygger videre på udtryk 2.9, hvor der tages yderligere faktorer i betragtning fra de tidligere udregnede afstandsmatricer. Sidste trin for den endelige score er at summere for alle par af sekvenser som LCB en dækker over. Dette har til formål at give en score som i højere grad filtrer tilfældige og såkaldte paraloge matches fra. Endeligt foretages der greedy breakpoint elimination, hvor konsekvensen af at fjerne en given LCB evalueres ud fra dens score, udregnet som forklaret ovenfor og foretages såfremt en forbedring opnåes. Iterativ forbedring og filtrering af LCB er De fundne LCB er forsøges forbedret ved at lave både ekstern og intern ankersøgning, der overordnet følger samme ide som i Mauve og tidligere beskrevet i afsnit Der anvendes dog den teknik, der adskiller sig fra den globale eksterne ankersøgning ved, at områder mellem LCB er nu inddeles i mindre afgrænsede områder, således at udførelsestiden i stedet kan bruges på at forbedre kvaliteten. De områder mellem LCB er som alignes, svarer ikke altid til homologe områder. Derfor forsøges disse som en ekstra garanti at blive identificeret ved at anvende såkaldt random-walk-statistik, baseret på den tidligere udregnede funktion PairScore(M) fra udtryk 2.9. Progressive Mauve er samlet set en videreudvikling af Mauve, der kan håndtere MUM s der kun er i en delmængde af sekvenserne, finde ikke eksakte ankre og i højere grad evaluere delresultater, for således at træffe et bedre valg. Efter at have gennemgået Mauve samt Progressive Mauve, kigges der i næste afsnit på en metode, kaldet Shuffle-LAGAN, der udkom et år før Mauveartiklen.

26 2.6. MULTIPLE ALIGNMENT MED LARGE-SCALE-EVENTS Shuffle-LAGAN Shuffle-LAGAN er et parvis alignment-værktøj, der er i stand til også at håndtere large-scale-begivenhederne rearrangements, inversions og duplications [2]. Shuffle- LAGAN benytter en kombination af eksisterende lokal og global alignment-værktøjer til at lave sin alignment gennem tre faser. Nummereringen i overskriften på hvert afsnit, fortæller hvordan Shuffle-LAGAN følger den generelle opskrift for multiple alignment med håndtering af large-scale-events. 1. Identifikation af homologe ankre mellem sekvenserne Shuffle-LAGAN laver først lokale alignments med værktøjet CHAOS (Chains of Seeds). CHAOS tager en seed-størrelse k, svarende til k-mer længden for Mauve, og et degenerecy-mål for, hvor mange nukleotider/aminosyrer der må være forskellige. Først findes en række af seeds mellem to sekvenser. Disse seeds findes ved for den første sekvens, at opbygge en træstruktur, kaldet en T-trie, over præfikses af k- mers. En T-trie adskiller sig fra en normal trie ved, at have en reference fra hvert blad til en knude, svarende til det suffiks, der er et tegn kortere. Seeds findes ved at betragte et tegn af gangen for den anden sekvens. For hvert tegn følges referencen til suffikset og det korrekte blad lokaliseres. Enkelte tegn i k-mers, der ikke er ens, håndteres ved at et antal stier, svarende til værdien for degenerency-målet, kan betragtes sideløbende i trien. Efter at have en række seeds, laves en sammenkædning af disse (chaining). Hvis et seed har overlap med et eller flere andre seeds, kædes de sammen, således at scoren over det samlede seed er den højeste af alle kombinationer af overlappende seeds. Efter kørslen af CHAOS, er der fundet en række af lokale alignments på formen L = (start 1,end 1,start 2,end 2,score,strand). Hvis end<start for en af sekvenserne, er det ensbetydende med, at den er i reverse-komplementet. 2. Gruppering af fælles delsekvenser Ved opbygning af et globalt map for de to sekvenser, tillader Shuffle-LAGAN at rækkefølgen af lokale alignment ikke alle skal have samme orientering, dvs. være kolinære, i begge sekvenser, og således er det muligt at medtage large-scale-events. Det globale map består af grupper af konsistente, lokale alignments [L 1,...,L n ], hvor det gælder at alle lokale alignments skal have samme retning i hver sekvens. Shuffle-LAGAN finder den højest scorende, konsistente delmængde af lokal alignments, ud fra en dynamisk algoritme. Resultatet efter anden fase svarer til c) på figur 2.8

27 22 KAPITEL 2. EVOLUTION OG ALIGNMENTS Figur 2.8: Figuren bruger dot-plots til at illustrere de forskellige events og hvordan Shuffle-LAGAN håndterer dem. Figur a) viser 3 typer af events: duplication som resulterer i, at en del af den ene sekvens, findes to steder i den anden sekvens. Inversion ses ved, at retningen på en diagonal er skiftet. En translokation vises ved, at en diagonal ikke ligger centreret. Figur b) viser et eksempel på hvordan homologe ankre mellem de de to sekvenser kunne se ud. Dette svarer til første trin i Shuffle-LAGAN. Figur c) viser med fed de udvalgte ankre, der skal inkluderes i alignment en. Figur d) viser de kolineær regioner, som hver bliver parvist alignet og inkluderet i det endelige resultat. 3. Parvis alignment af delsekvenser For hver kolineær blok laves nu en parvis alignment med værktøjet LAGAN. Dette er muligt da man nu har en opdeling, der viser hvilke blokke der hører sammen og kan alignes for sig selv, og hvordan sammenhængen mellem de enkelte blokke er. 2.7 Valg af metode I dette kapitel har vi kigget på alignments af sekvenser på mange niveauer. Det at aligne sekvenser er et af de mest brugte bioinformatiske værktøjer, da det danner grundlag for en lang række af videre analyser. Udviklingshistorien for strengalgoritmer, der danner grundlag for alignment værktøjer er lang, set i forhold til udviklingshistorien indenfor de meget specifikke bioinformatik værktøjer. I nyere tid er disse alignment-værktøjer blevet udviklet og tilpasset de behov, der er opstået som der gradvist er blevet mere tilgængelige data og viden på området. Antallet af algoritmer, der kan lave multiple alignments er forholdsvidt bredt. Metoder der tager højde for large-scale-events er straks mere begrænset, da det først i nyere tid er blevet sekvenseret tilstrækkeligt mange store genomer til at nødvendiggøre sådanne metoder. Vi ser derfor dette område inden for alignments, som et af de mest interessante at udforske, også fordi mængden af genomer forventes at blive forøget med stadig stigende kraft i fremtiden. Gennem dette kapitel har der tegnet sig et forholdsvis klart billede af at de fleste metoder, som i et vidst omfang enten kan håndtere store sekvenser eller tage høj-

28 2.7. VALG AF METODE 23 de for large-scale-events. De har som udgangspunkt følgende trin: identifikation af fælles delsekvenser, gruppering af fælles delsekvenser og alignment af sekvenerne baseret på de fundne grupperinger. Vi vælger at tage udgangspunkt i Mauve som metode, både hvad angår ankersøgning samt gruppering af disse. Havde vi taget udgangspunkt i Shuffle-LAGAN, ville vi have den begrænsning, at den kun håndterer to sekvenser, hvor Mauve og Progressive Mauve kan håndtere et vilkårligt antal. Sammenlignes Mauve med Progressive Mauve, så er sidstnævnte mere en udvidelse af Mauve end en ny metode. Derfor vil vi i dette speciale tage udgangspunkt i ideerne bag Mauve og senere have mulighed for at medtage yderligere teknikker. Valget af Mauve sikrer at vi er fleksible både hvad angår antal sekvenser, størrelsen af sekvenser og muliggører forbedringer af metoden, inspireret af andre metoder, så som Progressive Mauve.

29

30 K A P I T E L 3 UDVIKLING AF PROTOTYPE I dette og de efterfølgende to kapitler, gennemgås udviklingen af vores whole genome alignment algoritme. Vi har opdelt udviklingen af vores algoritme i tre forløb, hvor hver har haft deres eget formål. Opdelingen lægger op til en mere iterativ arbejdsproces, hvor der for hver iteration foretages en evaluering af hvordan den pågældende version, lever op til vores målsætning. Evalueringen giver også anledningen til, at identificere hvad den efterfølgende version skal fokusere på. Første version betegnes Prototypen og er en simpel implementering af Mauve, lavet for at give os en grundlæggende forståelse for de udfordringer, der opstår i forbindelse med en implementering af Mauves algoritme. Herefter har vi udviklet en Draftudgave i kapitel 4, der algoritmisk lægger sig tæt op af Mauve, idet reverse-komplementet medtages. Her introduceres brugen af CLC bio s framework, som giver en række fordele, hvilket vi kommer nærmere ind på senere. Sidst har vi en version betegnet Final beskrevet i kapitel 5, der er en videreudvikling af Draftudgaven, baseret på ideer vi har fået fra andre artikler, samt vores egne observationer gennem udviklingsforløbet. Der er flere ideer bag det, at starte med udviklingen af en prototype: Det sikrer at vi får et bedre indblik i, hvor meget arbejde, der ligger i hver fase af Mauve, samt en ide om hvor vi skal ligge fokus senere, for at få en velfungerende implementering. For at sikre en hurtig udvikling af Prototypen, har vi fra starten af, bevidst valgt nogle begrænsninger i vores implementering. En væsentlig simplificering er, at vi ikke betragter reverse-komplementet af sekvenserne. Dette giver færre tilfælde i algoritmen, som skal overvejes i hver fase, men ændrer ikke på hvilke overordnede 25

31 26 KAPITEL 3. UDVIKLING AF PROTOTYPE trin vi skal implementere. Vi undlader også et trin i algoritmen, der iterativt forsøger at finde nye, samt forbedre, de fundne kolinære blokke også kaldt LCB er. Som konsekvens heraf, forventer vi en alignment af lavere kvalitet. De følgende afsnit beskriver implementeringen af de forskellige faser af Mauve for Prototypen. Algoritmerne for hver fase i Mauve, gennemgås i den rækkefølge de forekommer. Først kigges på seed-and-extend algoritmen, der bestemmer MUM s. Efterfølgende vises hvordan Greedy Breakpoint Elimination algoritmen bruges til at gruppere MUM s i LCB er. 3.1 Ankersøgning med seed-and-extend Seed-and-extend algoritmens opgave er at finde maksimale matchende delstrenge mellem sekvenserne betegnet MUM s. Dettes gøres gennem flere trin hvor der først findes delstrenge af længde k separat for hver sekvens, de såkaldte k-mers. Nogle af disse k-mers kan så senere grupperes til ankre (også kaldet seeds i Mauve), der har den egenskab at de er unikke og findes i alle sekvenserne. Ankrene bruges til at bestemme MUM s, ved at udvide dem til maksimale matches, som udgør resultatet af seed-and-extend algoritmen. I de næste underafsnit beskrives hvert trin af seed-and-extend mere detaljeret Identifikation og sortering af unikke k-mers For hver sekvens laves der et gennemløb, hvor der oprettes en liste af alle delstrenge af længde k. Hver liste sorteres leksikografisk stigende efter delstrengene ved at benytte Java s Collections library. Næste trin fjerner alle k-mers der ikke er unikke. Eftersom listen er sorteret er det nok at sammenligne en k-mer med de omkringliggende, for at afgøre om den er unik eller ej. Altså laves der kun et enkelt gennemløb af hver liste, for at fjerne alle duplikater Identifikation af ankre Eftersom vi kun er interesserede i MUM s med multiplicitet G, altså MUM s der er tilstede i alle sekvenser, kan vi se helt bort fra de MUM s, der kun er i en delmængde af sekvenserne. Såfremt vi ønskede at lave et guide tree til vores senere alignmentfase (afsnit 3.3), ville det være nødvendigt at holde styr på nogle MUM s, der kun optræder i en delmængde af sekvenserne, med det formål at identificere hvilke sekvenser der er tættest beslægtet. I første omgang findes ankre ved at gennemløbe listerne af k-mers, som gøres ved leksikografisk sammenligning af indgangene (også illustreret på figur 3.1).

32 3.1. ANKERSØGNING MED SEED-AND-EXTEND 27 ˆ Š Œ ˆŽ ˆ Š Œ ˆ ˆ Š Œ ˆ Figur 3.1: Gennemløb af tre lister med k-mers, for at finde ankre. De markerede indgange i hver liste svarer til hvor langt gennemløbet er nået. Der betragtes to lister ad gangen her vist ved to pile. Den leksikografisk mindste indgang giver anledning til at der kigges på den næste k-mer i listen. Dette gennemløb foretages næsten som en fletning af listerne. Eftersom sammenligningerne foretages parvist, er der to tilfælde for denne sammenligning: Hvis den ene k-mer er mindre (leksikografisk) end den anden, kigges der på den næste k-mer i den liste, der havde den mindste k-mer. Hvis de to k-mers er ens, er der fortsat potentiale for et anker, og derfor kigges der på lignende vis, på de resterende lister. Det bemærkes at overstående metode kun virker, fordi vi udelukkende betragter MUM s med multiplicitet G. Derfor kan vi tillade os, at gå videre til næste k-mer så snart, to k-mers ikke er identiske. Resultatet af ovenstående er identifikation af ankre som i næste underafsnit udvides til MUM s. Oprettelse og udvidelse af MUM s Næste skridt er at oprette MUM s ud fra de unikke k-mers, der eksister i alle sekvenser, betegnet ankre. Hvis et anker ikke er del af en eksisterende MUM, udvides den i begge retninger, så længe nukleotiderne matcher i alle sekvenser. Dette skaber en MUM, da k-meren i hver sekvens er unik og de er blevet udvidet så de er maksimale. Vi benytter et boolean array til at tjekke om hvorvidt en k-mer allerede er indeholdt i en MUM. Hver indgang i array et angiver, hvorvidt en given nukleotid, er indeholdt i en eksisterende MUM. Dette giver en opslagstid på O(1), men på bekostning af O(n) plads. For det menneskelige kromosom X, der er ca. 140 mbp langt, vil det kræve 140 MB hukommelse, at repræsentere boolean array et, hvilket godt kan lade sig gøre da de fleste workstations i dag har 2 GB hukommelse eller mere. Ved at bruge et boolean array adskiller vi os her fra Mauve, der i stedet bruger en hashtabel. Dette valg er foretaget for at få en simplere løsning.

33 28 KAPITEL 3. UDVIKLING AF PROTOTYPE š œ ž š œ Ÿ š œ ž š œ Ÿ š œ Ÿ Figur 3.2: Figuren viser hvorfor en unik k-mer altid giver anledning til den samme MUM. Der vises to sekvenser, hvor de orange markerede områder i sekvenserne udgør en MUM. Der er også angivet to k-mers. k-mer 2 har i Sekvens 2 en dublet betegnet k-kmer 2. Denne dublet betyder at k-mer 2 og k-kmer 2 vil være blevet fjernet i Sekvens 2 og derfor ikke kunne danne grundlag for den markerede MUM. k-mer 1 er unik i begge sekvenser og kunne derfor godt have givet anledning til den markerede MUM. Konsekvensen af ovenstående er at k-mers efter eliminering af dubletter, altid resulterer i den samme MUM. Det er tilstrækkeligt at have ét array for første sekvens, frem for G forskellige array s, da elimineringen af k-mer dubletter sikre at de resterende k-mers ikke kan være indeholdt i mere end én MUM. Præcis hvorfor en k-mer altid giver anledning til den samme MUM er illustreret af figur 3.2. Brugen af et boolean array frem for Mauves løsning kan give en forskel i algoritmens resultat, såfremt der er en lang MUM der kasseres, fordi den overlappes fuldt af to mindre MUM s. Her burde resultatet være, at den længste MUM blev bibeholdt og de mindre MUM s fjernet. Vi forventer dog at dette specialtilfælde sjældent forekommer. Håndtering af overlaps mellem MUM s Selvom MUM s er unikke matches, så kan der stadig være delvise overlaps mellem dem. Disse overlaps ønsker vi at eliminere, for at få et entydigt sammenligningsgrundlag til Greedy Breakpoint Elimination fasen, som gennemgås i næste afsnit. Grundet den måde k-mers bliver fundet på, er det garanteret at to MUM s kun delvist kan overlappe med to andre MUM s. Som beskrevet i [5], kan en nukleotid højest være indeholdt i to MUM s i samme orientering (altså to i forward- og to i reverse-retningen). Kombineres disse to egenskaber, har vi at der kun kan forekomme et delvist overlap mellem to MUM s. Kigges der på, hvordan delvise overlaps mellem MUM s er begrænset så er der to tilfælde. Et med overlap i starten og et med overlap i slutningen. Dette giver en simplificering, da man således kun har få tilfælde at skulle tage højde for. Grundet denne egenskab, kan delvise overlaps mellem MUM s findes således: Der kigges på én sekvens ad gangen. Alle MUM s sorteres efter startpositionen i

34 3.2. GRUPPERING AF MUM S I KOLINÆRE BLOKKE 29 denne sekvens. Overlappende MUM s vil nu komme lige efterhinanden, hvorfor det er nok at lave et enkelt gennemløb for hver sekvens. Overlaps mellem MUM s håndteres som i Mauveartiklen [5], hvor den længste MUM bibeholdes og den korteste MUM får reduceret dens længde. Selvom MUM s fra starten ikke kan være fuldt indeholdet i en anden MUM, så kan en MUM godt overlappes fuldstændigt, som følge af reducering af størrelsen gennem tidligere håndtering af overlaps. I dette tilfælde reduceres længden til nul og den tilsvarende MUM fjernes efterfølgende. Næste afsnit kigger på hvordan MUM s fundet som beskrevet i dette afsnit, kan grupperes til større enheder der har samme orientering i hver sekvens. 3.2 Gruppering af MUM s i kolinære blokke Grupperingen af MUM s i kolinære blokke, de såkaldte LCB er, tager udgangspunkt i Mauves algoritme. Der identificeres først breakpoints, der angiver hvordan en mængde af MUM s kan danne en LCB. For at finde disse breakpoints, laves først en fortløbende nummerering af MUM s, der angiver rækkefølgen mellem dem i første sekvens, sorteret efter startposition. Nummereringen foregår ved brug af et label for hver MUM. Næste skridt i algoritmen er at betragte de resterende sekvenser et ad gangen, hvor MUM s nu sorteres efter startposition i den sekvens der betragtes. Fordi vi kun betragter forward retningen i Prototypen, kan vi nøjes med én af de tre regler som nævnes i afsnit Nemlig at se hvorvidt M i.label+1 M i+1.label, for at se om der er et breakpoint mellem M i og M i+1. Inden LCB erne findes, sorteres MUM s igen efter startposition i første sekvens, da det er i forhold til denne rækkefølge, at breakpoints er defineret. Samtidig med genereringen af LCB er finder sted, tjekkes det om der er en stor afstand mellem de MUM s, der udgør en LCB. Hvis mellemrummet er for stort til at foretage en traditionel multiple alignment, bliver LCB en splittet op i to. Vi har i vores Prototype sat denne grænse til at være nukleotider. Vi har valgt at bruge dette tal da det er stort nok i de fleste tilfælde til at vi kan identificere en LCB og uden at tage for lang tid i praksis at aligne. Eftersom Prototypen ikke har nogen efterfølgende raffinering af LCB erne, har den ikke mulighed for at finde flere MUM s der kan bruges til at reducere de områder der skal alignes efterfølgende Identisk med Mauve, gentager vi overstående algoritme en række gange, hvor vi for hver iteration finder de LCB er som har den mindste vægt og fjerner de pågældende MUM s. Dette gentages ind til minimumsstørrelsen når 3 k hvor k er den oprindelige k-mer størrelse. Denne grænse kommer fra Mauveartiklen. Den simpleste implementering af ovenstående er for hver iteration at genberegne alle LCB er. Dette undgår vi ved at fjerne de pågældende LCB er direkte og

35 30 KAPITEL 3. UDVIKLING AF PROTOTYPE nøjes med at se hvorvidt de omkringliggende LCB er efterfølgende kan sammenflettes. Det fremgår ikke af [5] hvordan denne sammenfletning foretages men vi har valgt en fremgangsmåde til at flette LCB er hvor algoritmen for at finde LCB er ud fra MUM s benyttes på LCB er i stedet. Kort fortalt fjerner vi først alle de LCB er som havde en minimumsvægt. Så sorterer vi LCB er efter en sekvens af gangen, hvor der for den første sekvens foretages en nummerering igen og til sidst angiver for LCB er om der stadig er et breakpoints mellem dem. 3.3 Gapped alignment Det sidste skridt af vores Prototype implementering er, at få alignet områderne mellem MUM s internt i LCB erne. Dette gøres ved benytte et traditionelt multiple alignmentværktøj. Vi benytter Muscle [7] til denne opgave, hvilket nyere versioner af Mauve også gør (version 1.2 og frem). Valget af Muscle skyldes at denne algoritme har en god afvejning mellem hastighed og kvalitet. Som oftest er man mindre interesseret i en alignment med høj kvalitet når man betragter hele genomer, fordi man i så fald bruger meget lang tid på en alignment, og man alligevel først efterfølgende udvælger de områder af genomerne, man vil lave videre analyser på. Efterfølgende opbygger vi en alignment ud fra LCB erne. Dette gøres ved at kombinere MUM s fra en given LCB med de mellemliggende alignments lavet af Muscle. Der outputtes i Mauves XMFA format 1. XFMA formatet beskriver for hver LCB: start og slut position i hver sekvens samt den resulterende multiple alignment. Dette resultat kan efterfølgende vises i Mauves grafiske viewer, som brugt i evalueringen af vores Prototype. 3.4 Evaluering af Prototype Formålet med Prototypen er, at sikre den grundlæggende forståelse for algoritmen bag Mauve, samt se hvilke faser der skal fokuseres på med hensyn til senere udvikling. Evaluering af Prototypen tager udgangspunkt i følgende aspekter, hvilket senere også vil være tilfældet for evaluering af Draft og Final. Evaluering af korrekthed og kvalitet: Vi gennemgår de tests vi har lavet for at sikre algoritmens korrekthed. Herudover evaluerer vi kvaliteten af de alignments algoritmen producerer i forhold til en reference. Hukommelsesforbrug: Vi tester hvor meget hukommelse vores algoritme bruger i forhold til implementeringen af Mauve. Vi måler forbruget i Java ved at 1

36 3.4. EVALUERING AF PROTOTYPE 31 først kalde garbage-collectoren og derefter forespørge Java om hvor meget hukommelse der bruges. Tidsforbrug måles og sammenlignes med Mauve. De teoretiske forudsætninger, samt detaljer om test-opstillinger og test-data for hver af disse aspekter, er nærmere beskrevet i kapitel 6. Evaluering af Prototypen er primært baseret på datasættet med tre bakterier, som vi har valgt at betegne 3bac Korrekthed og kvalitet For Prototypen har mængden af tests for korrekthed af resultater været begrænset, da Prototypen ikke vil blive genanvendt direkte til de næste versioner. Fokus har været, at forstå metoden og få den til at virke på enkelte datasæt. Evaluering af både korrekthed og kvalitet bestod derfor i en visuel sammenligning af alignments vha. Mauve-vieweren. Et eksempel på dette fremgår af figur 3.3 og 3.4. Af disse illustrationer ses det at Prototypen opfører sig som forventet, nemlig at de fleste større LCB er findes. Områder der er i reverse-retning er ikke fundet, hvilket er som forventet. Dette antyder derfor at vores Prototype fungerer som ønsket. For at få en mere præcis idé om hvor godt Prototypen klare sig, har vi prøvet at vurdere kvaliteten af den fundne alignment med udgangspunkt i en reference. Til dette formål har vi konstrueret et kvalitetsmål. Kvalitetsmålet består af to størrelser betegnet henholdsvis Sensitivity og PPV. Sensitivity angiver hvor stor en del af en reference, der er medtaget, mens PPV angiver hvor stor en del der taget med, som ikke er i referencen. Begge kvalitetsmål kan variere mellem 0 og 1, hvor 1 er bedst. Sensitivity og PPV er nærmere beskrevet i afsnit Vi nøjes med at sammenligne Prototypen med Mauve 1.2 på 3bac. Vi har benyttet Progressive Mauve som reference. Prototype Mauve 1.2 Sensitivity 0,6096 0,9300 PPV 0,9985 0,9983 Ovenstående tabel bekræfter resultaterne fra tidligere, nemlig at Prototypen som forventet har en betydelig lavere sensitivitet end Mauve. Dog er PPV tæt på 1 hvilket indikerer, at det medtagne stemmer overens med Mauve. Resultaterne indikere, at vi har fået en implementering der godt nok ikke finder alle typer af events, men det fundne er tilgengæld korrekt. Vi har desuden prøvet at se hvor stor betydning grænsen på nukleotider for opsplitning af LCB er, har for sensitiviteten. Ved at flytte grænsen op på steg sensitiviteten til 0,6501, mens PPV var stort set uændret. Såfremt man kun er interesseret i at finde LCB erne, er denne ændring værdifuld, men hvis gapped alignment medtages, giver ændring anledning til at der bruges betydelig længere tid og mere hukommelse i denne fase.

37 32 KAPITEL 3. UDVIKLING AF PROTOTYPE NC_ fasta (no annotations loaded) NC_ fasta (no annotations loaded) NC_ fasta (no annotations loaded) Figur 3.3: Illustration af en alignment lavet af Prototypen NC_ fasta (no annotations loaded) NC_ fasta (no annotations loaded) NC_ fasta (no annotations loaded) Figur 3.4: Illustration af en alignment lavet af Mauve 1.2. Sammenholdes den med den tidligere for Prototypen fra figur 3.3, ses generelt en stor lighed undtagen for områder i reverse-retningen. Områder i reverse-retning er på den nederste-del af linjen, hvor dem i forward-retning er på den øverste.

38 3.4. EVALUERING AF PROTOTYPE Løbende hukommelsesforbrug for Prototype og Mauve 1.2 Prototype-noalign Mauve-1.2-noalign 400 Hukommelse [mb] Tid [s] Figur 3.5: Her ses hukommelsesforbruget for Prototypen over tre sekvenser. Det ses at seed-and-extend fasen bruger mest hukommelse. Trappen i starten af grafen skyldes, at der søges efter k-mers for hver sekvens Hukommelsesforbrug Hukommelsesforbruget for Prototypen forventes at være meget stort i forhold til Mauve, da vi ikke har haft nogen hensyntagen til dette område i vores implementering. En test for datasættet med tre bakterielle genomer (3bac) bekræfter dette, da det samlede forbrug for Prototypen kommer op på omkring 400 MB, hvor Mauve 1.2 kan nøjes nøjes med under 50 MB (som ses af figur 3.5). Af figuren ses yderligere at ankersøgning i starten af hvert sekvensgennemløb, tager en del ekstra hukommelse. Efter at have fundet alle k-mers, bruges der efterfølgende mindre hukommelse, hvorfor det giver mening at lægge fokus på hukommelsesforbruget for seedand-extend og derved evnen til at skalere til større sekvenser, i vores næste version. Efter identifikation af ovenstående problem, kiggede vi på hvor mange af disse k-mers, der reelt gav anledning til en MUM. Vi gjorde dette for at få en ide om hvorvidt vi skulle overveje en anden datastruktur til k-mers, efter disse er blevet fundet. Det viste sig, at ud af k-mers, bliver kun 6 153, svarende til 0,06% bevaret. Derfor skal videre arbejde fokusere på en kompakt struktur, der muliggører hurtig oprydning af de ubrugte k-mers.

39 34 KAPITEL 3. UDVIKLING AF PROTOTYPE Tidsforbrug Ved brug af det genererede datasæt 3bsimdiff, med tre bakterier af forskellig længde, har vi set på hvordan udførelsestiden hænger sammen med antallet af nukleotider i sekvensen. På figur 3.6 ses en sammenligning mellem vores Prototype og Mauve 1.2. Det fremgår af den øverste graf, at Mauve 1.2 klarer sig markant bedre end vores Prototype. Vores Prototype har dog en del ulemper i gapped alignment fasen: For at lave alignment med et eksternt program skriver Prototypen først til disken, kører det eksterne program og læser herefter resultatet ind fra disken. Mauve kan kommunikere direkte med Muscle og slipper således for at bruge disken. Prototypen mangler raffinering af de fundne LCB er, såldes at ekstra ankre kan findes, der giver anledning til færre store områder, som skal alignes. En stor del af de alignments vi foretager med Muscle er meget små, og giver derfor et relativt stort overhead i forhold til Mauve 1.2, og er formegentligt hovedårsagen til, at vores Prototype er så meget langsommere end Mauve 1.2 til at foretage alignments. Hvis der ses bort fra gapped alignment fasen, er Mauve 1.2 stadig overlegen til trods for at den medtager reverse-komplement og altså laver en del mere arbejde end Prototypen. Det er altså nødvendigt at optimere på alle faser i algoritmen for at komme tættere på Mauve Erfaringer Ud fra erfaringerne ved at lave Prototypen, har vi sat følgende målsætninger for næste version: For at implementere hele Mauvealgoritmen skal vi yderligere inkludere understøttelse for MUM s og LCB er i reverse-retning. Desuden skal raffineringsfasen inkluderes, for at forbedre kvaliteten af det endelige resultat. Seed-and-extend fasen er kritisk for udførelsestiden og hukommelsesforbruget. Det er vigtigt at denne fase bliver lavet med kompakte og effektive datastrukturer. Hukommelsesforbruget skulle gerne så langt ned at selv relativt store sekvenser kan alignes på en almindelig workstation. Siden Mauve udkom i 2004, er det blevet almindeligt med flere-kernede CPU er. Ved at forsøge at parallelisere så mange dele af algoritmen som muligt, kan vi forbedre den praktiske udførelsestid.

40 3.4. EVALUERING AF PROTOTYPE Tidsforbrug for Prototype og Mauve 1.2 Prototype Mauve Tid (sek) Laengde (mbp) Tidsforbrug for Prototype og Mauve 1.2 uden endelig alignment Prototype-noalign Mauve-1.2-noalign 250 Tid (sek) Laengde (mbp) Figur 3.6: Øverste graf viser samlet tidsforbrug for Prototypen og Mauve 1.2. Nederste graf viser tidsforbruget hvor gapped alignment fasen er udeladt.

41

42 K A P I T E L 4 UDVIKLING AF DRAFT Efter at have fuldført første iteration af udviklingsforløbet, hvor vi endte med en Prototype, af en whole genome aligner, beskrives her den næste iteration, der omhandler implementeringen af Draftudgaven. Denne udgave vil benytte CLC bio s framework og kunne bruges som et plugin til CLC bio s Workbench. Følgende kapitel har overordnet samme struktur som kapitel 3 for udviklingen af Prototypen. Først kigges der dog på konsekvenser af, at vi benytter CLC bio s framework. Eftersom meget af udviklingsforløbet er en fortsættelse af Prototypen, vil vi især lægge vægt på, at beskrive de algoritmiske ændringer, der er blevet inkluderet i denne version. 4.1 Introduktion til CLC bio s framework Ved udviklingen af Prototypen var formålet at få en funktionel udgave, der kunne give os større indblik i Mauve. Vi havde således svært ved at lave nogle kvalificerede antagelser om, hvordan vi bedst muligt kunne repræsentere data. I denne iteration derimod vil vi gerne inddrage vores erfaringer og lave en mere hukommelseseffektiv datarepræsentation. CLC s framework, som består af en lang række af datatyper og algoritmer til analyse af biologisk data, giver os i denne forbindelse, adgang en lang række af de datastrukturer vi har brug for. CLC bio s framework giver også nogle nye udfordringer. Vi er nødt til at implementere en plugin del, for at vores algoritme kan benyttes via CLC Workbench. Det at anvende et framework giver anledning til en hurtigere udvikling, men benytter 37

43 38 KAPITEL 4. UDVIKLING AF DRAFT også mindre specialiseret kode og kan derfor sommetider være mindre effektivt. Dette kan føre til større hukommelsesforbrug og længere udførelsestid Fysiske rammer CLC bio s framework er udviklet til brug på workstations. Dette betyder at man som udgangpunkt regner med at der er installeret 2 GB hukommelse i disse maskiner. CLC vil gerne have at man har mulighed for at aligne mindre bakterie genomer med hinanden (typisk 3 5 bakterier af 5 10 mbp), indenfor disse rammer. For større sekvenser har brugerne som regel en større maskine til rådighed, men CLC s målsætning er at der er mulighed for at lave en afvejning mellem hukommelses- og tidsforbrug, hvor det er muligt, således at brugerne ikke forhindres i at kunne bruge algoritmen Repræsentation af sekvenser og alignments CLC bio s framework har visse begrænsninger. Eksempelvis er deres datastruktur til sekvenser ikke i stand til, at håndtere sekvenser på over mbp nukleotider. Dette er dog ikke et problem for vores algoritme, da vi kun har valgt at arbejde os målrettet hen mod at kunne aligne kromosomer på omkring 140 mbp. Begrænsingen i CLC s framework betyder at vi ikke vil være i stand til at kunne aligne det menneskelige genom, da det fylder ca mbp 1. Datastrukturen for sekvenser i CLC bio s framework bruger en byte til at repræsentere en nukleotid. Det ville i teorien være muligt, at nøjes med 2 bit, men eftersom CLC s framework bliver brugt i mange forskellige sammenhænge, er det nødvendigt at tage hensyn til, at eksempelvis store og små bogstaver kan bruges som indikator for, hvilke nukleotider i en sekvens, der er mest pålidelig sekvenseret. Af denne årsag, er det fornuftigt at bruge en byte, til at repræsentere en nukleotid. Sekvensdata læses gennem en iterator, som både kan læse i forward og reverse retning. En alignment i CLC s framework betragtes som en transformation af en sekvens. Alignments kan repræsenteres som et boolean array, der angiver om en given position i sekvensen skal udskrives, eller om der skal indsættes et gap. Sekvens: AACTGACG (8 byte) Sekvens (aligned): AAC--T--GA-CG (8 byte+5 byte=13 byte) Boolean repræsentation: TTTFFTFFTTFTT (8 byte+13 bit=10 byte) Længde repræsentation: 3, ~2, 1, ~2, 2, ~1, 2 (8 byte+7 byte=15 byte) boolean repræsentationen har den fordel, at den kan komprimeres. At repræsentere et tegn for sekvensen (inklusiv gap-tegn) kræver kun et bit, og det er uanset 1

44 4.1. INTRODUKTION TIL CLC BIO S FRAMEWORK 39 Figur 4.1: Flere datatyper i CLC s framework benytter en transparent caching mekanisme, således at data kan gemmes på disken, hvis der er mangel på hukommelse. Hvis data skal bruges igen, bliver det automatisk genindlæst i hukommelsen. hvor mange forskellige tegn sekvensen kan have. Eftersom der ofte ses mange gaps eller nukleotider i træk, når sekvenser alignes, laver frameworket en anden repræsentation internt, hvor en alignment betragtes som en række af længdeangivelser. Længdeangivelser viser skiftevis hvor mange nukleotider og hvor mange gaps der kommer i sekvensen. For det viste eksempel er boolean repræsentationen dog den mest effektive repræsentation IO funktioner i CLC bio s datastrukturer CLC har i deres framework haft en målsætning om ikke at holde mere data i hukommelsen end nødvendigt, således at man kan arbejde med større sekvenser på en almindelig workstation. Dette opnås ved at CLC s sekvens samt liste repræsentationer bruger lazy-evaluering ved indlæsning og skrivning, hvilket vil sige, at den kun holder data i hukommelsen, når det skal bruges. Dette er illustreret på figur 4.1. Afhængig af hvor meget hukommelse maskinen har, tildeles en hvis procentdel til en CLC cache, som frameworket bruger til at holde på data, der anses for at være relevant. Hvis man har meget hukommelse, kan frameworket holde en stor sekvens i cachen, således at tilgang bliver meget hurtig. Omvendt kan den i tilfælde af en lille mængde tilgængelig hukommelse, nøjes med at læse en brøkdel af sekvensen ind ad gangen. CLC s datatyper giver os derved mulighed for transparent at inkludere en smart måde at håndtere store datamængder på. Det er dog ikke fuldstændig transparent, idet vi er nødt til at lave nogle overvejelser omkring brugen af cachen, for at sikre at vi ikke laver nogle gennemløb der tager meget lang tid, når der skal hentes ind fra cachen. Dette kan fx være at udføre liste-operationer så sekventielt som muligt de steder hvor vi har store lister, der med fordel kan gemmes midlertidig på disken, for at spare plads i hukommelsen.

45 40 KAPITEL 4. UDVIKLING AF DRAFT Figur 4.2: Valg af data og parametre foretages via en guide gennem CLC Workbench Plugin til CLC bio s Workbench Ved at bruge CLC s framework er det muligt at bruge vores aligner som plugin til CLC s Workbench. Det betyder at brugerene af CLC Workbench kan hente vores plugin og integrere det direkte i deres arbejdsgang, uden at skulle køre det som et eksternt program. Figur 4.2 viser hvordan man bliver guidet gennem valg af sekvenser, der skal alignes. Når programmet er startet er det muligt, at følge med i hvor langt man er nået, hvilket kan ses på figur 4.3. Når man laver alignments af hele genomer, gøres det oftest som første trin i en større analyse. Af denne grund er det meget naturligt, at sammenkæde vores værktøj med en lang række, af andre biologiske værktøjer, således at de kan bruges sammen uden at der opstår problemer med eksempelvis formatet for en alignment. Efter at have kigget på hvad CLC bio s framework kan tilbyde og hvordan vi integrerer os med CLC Workbench, så kigger de næste afsnit på udviklingen af Draftversionen. 4.2 Ankersøgning med seed-and-extend Seed-and-extend algoritmen for Draft udvides til også at tage højde for reversekomplementet, samt at kunne håndtere større sekvenser. Dette giver en række æn-

46 4.2. ANKERSØGNING MED SEED-AND-EXTEND 41 Figur 4.3: Et statusvindue opdateres løbende, mens der foretages en alignment. dringer i hvordan k-mers sorteres og MUM s efterfølgende identificeres. Et alternativ til seed-and-extend algoritmen, er at benytte et såkaldt suffix-træ. Et suffix-træ for G sekvenser kan laves ved at konkatenere alle sekvenser, hvor hver sekvens er adskilt af et unikt tegn. Herefter indsættes alle suffixes af den kombinerede streng i en træ-struktur. MUM s kan nu identificeres ved at finde knuder i træet, der har et blad for hver af de G sekvenser. Fordelen ved at bruge suffix-træer er, at det kan finde flere MUM s end seed-and-extend, da det ikke er begrænset til en k-mer størrelse. Desuden kan et suffix-træ opbygges i O(Gn) tid, hvilket er lavere end tiden for seed-and-extend, der er O(Gn log(gn)+g 2 n). Vi har valgt ikke at benytte suffix-træer, da størrelsen af suffix-træet kan være meget stort, og det ikke er simpelt at persistere suffix-træet på disken, uden at det resulterer i et stort ydelsestab Sortering af unikke k-mers Kigges der på ankersøgning, set i forhold til den i Prototypen (afsnit 3.1.1), så er der fra start flere ændringer. Vigtigst var det at få inkluderet reverse-komplementet. Vi ville også gerne minimere hukommelsesforbruget og lave en løsning som kan anvendes på store sekvenser, da det netop var denne fase som brugte mest hukommelse.

47 42 KAPITEL 4. UDVIKLING AF DRAFT For at gøre pladsforbruget mindre, er det vigtigt at repræsentere k-mers så effektiv som muligt. Eftersom hver k-mer i starten af denne fase har en fast længde, er det redundant at gemme denne for hver. De eneste to informationer der er unikke for hver k-mer, er start position samt retning. Derfor er en mulig repræsentation, at have et array bestående af integer, hvor den numeriske værdi angiver start-positionen og fortegnet angiver retningen, på samme måde som det gøres i Mauveartiklen [5]. For at kunne fjerne dubletter effektivt, sættes startpositionen for disse til -1, således at de alle kan fjernes samtidig ved et gennemløb af listen over k-mers, fremfor at lave mange små liste-operationer. For bedre at kunne håndtere store sekvenser med hensyn til hukommelsesforbruget, har vi valgt at opsplitte array et over k-mers, som skal sorteres, i en række af blokke. Vi benytter radix-sort på hver blok til selve sorteringen. Opsplitning i blokke gør det nødvendigt, at flette de sorterede resultater sammen til sidst. Figur 4.4 viser hvordan hvert array for en sekvens splittes i et nødvendigt antal blokke. Figuren viser ligeledes at når de sorterede k-mers flettes sammen, så gemmes resultatet i et IoArray.Int. Denne type har en cache funktionalitet som beskrevet i afsnit og kan derfor rumme alle k-mers, så længe der er plads på harddisken. Hvad der yderligere ses af figur 4.4 er, at hver opgave med at håndtere blokke, sortere disse og sammenflette resultater er uafhængig af andre sekvenser. Dette betyder at disse opgaver kan paralleliseres på maskiner med flere kerner. Dog er der den begrænsning at der kun kan paralleliseres i forhold til antallet af sekvenser. Endvidere kan den ekstra hukommelse der kræves, give et ydelsestab der matcher det der vindes ved parallelisering, såfremt det er nødvendigt at bruge disken. Radix-sort Vi har taget udgangspunkt i radix-sort [9, s ] til sortering af k-mers. Ud over opsplitning af array et med k-mers, så bliver de tilhørende sekvensdata også klargjort i hukommelsen før sortering. Dette er vigtigt, da sortering af k-mers kan give anledning til spredte opslag i sekvensdata, hvilket er uheldigt hvis de befinder sig på disken. Det at vi repræsenterer en k-mer i reverse-komplementet ved et negativt index, betyder at radix-sort skulle tage højde for dette. Hvis der haves en k-mer længde på k, så vil hver karakter i sekvensen indgå i k forskellige k-mers i reversekomplementet. Dette medfører at hver karakter skal oversættes til sit komplement k gange. Ydermere skal der kigges på om en k-mer ligger i reverse-komplementet eller ej, hvilket også tager tid. Af denne grund vælger vi fra start at tage reversekomplementet af sekvensdata for hele den blok der skal sorteres, hvilket betyder at vi ikke skal identificere hvad der er k-mers for reverse-komplementet. Vi bruger derfor 4m hukommelse på data for hver blok, hvor m er blokstørrelsen, da k-mers

48 4.2. ANKERSØGNING MED SEED-AND-EXTEND 43 µ µ ¹µº byte[] byte[]»¼½µº¹ int[] int[] int[] int[] ¾º µºà Á int[] int[] int[] int[] Âõ À Á ª«IoArray.Int ª«IoArray.Int ÄÅÄƹ ±²±³ IoList<MUM> Figur 4.4: Denne figur viser et eksempel hvor der indledningsvis haves to sekvenser som kan behandles parallelt. Lister over k-mers for disse sekvenser opsplittes i et tilstrækkeligt antal blokke for at kunne være i hukommelsen som efterfølgende sorteres. Netop fordi listerne opsplittes er det også nødvendigt at flette resultaterne. Endeligt kan en liste over MUM s findes. samt sekvensdata bruger 2m hukommelse i hver retning. Dette holder sig stadig inden for O(n). Det kan dog medføre at vi som resultat af et øget hukommelsesforbrug, kan blive nødt til at foretage flere opsplitninger i mindre blokke. Vi har lavet en hastighedsoptimering for radix-sort ved at sørge for anvende to karakterer som bucket frem for kun én karakter. Dette bevirker at antallet af runder med radix-sort halveres. Det sker dog på bekostning af hukommelsesforbruget for de interne datastrukturer af radix-sort. Ved at kun bruge én karakter kræves =3KB, da der haves tre datastrukturer af integers for hver mulig karakterværdi, hvilket repræsenteres af en byte i CLC s framework. Når to karakterer betragtes stiger forbruget til , hvilket vil sige 768 KB, som ikke anses at være et problem. Hvis man derimod betragter tre tegn kræves 48 MB, hvilket er unødvendigt stort sammenlignet med hvad sekvensdata kan fylde. Det bør bemærkes at det umiddelbart godt for nukleotider vil kunne lade sig gøre at betragte mere end to karakterer i radix-sort, såfremt de blev pakket mere effektivt og ikke hver krævede en hel byte. Men da CLC s framework tvinger os til at bruge en byte på hver nukleotid, er vi begrænset til at betragte to karakterer ad gangen.

49 44 KAPITEL 4. UDVIKLING AF DRAFT Sammenfletning Når der haves blokke af k-mers så skal disse flettes sammen. Dette kan ganske simpelt gøres for to blokke som var det sidste trin af en merge-sort[9, s ]. Hvis der haves mere end to sekvenser har vi overvejet to metoder at flette disse på. En metode er at flette to blokke af gangen, hvilket kan gentages ind til der kun haves én blok. En anden lidt mere kompliceret metode ville være at betragte alle blokke samtidigt og så opretholde eksempelvis en heap der indeholder den pågældende indgang i hver blok som bliver betragtet. Vi har valgt førstnævnte metode alene på baggrund af dens simplicitet Identifikation af MUM s Før MUM s kan findes er det nødvendigt at gennemløbe listen af k-mers og fjerne dubletter. Dette gøres trivielt ved at sammenligne på hinanden efterfølgende k-mers for at se om de er ens. Når dette er tilfældet, så markeres de begge som ikke eksisterende, som nævnt tidligere. Fremgangsmåden for at finde MUM s vi benytter er meget lig den fra Prototypen (afsnit 3.1.2). Vi kan stadig tillade os kun at kigge på MUM s med multiplicitet G og lave samme gennemløb. Der er dog et par ekstra hensyn som skal tages. Vi betragter nu reverse-komplementet, hvilket kan give konflikter idet vi stadig benytter metoden fra Prototypen med et boolean array til detektion af eksisterende MUM s. Af denne grund har vi valgt at undlade og kigge på reverse-komplementet i den første af de sekvenser vi sammenligner. Dette medfører kun fordele og gør dels at vi kan benytte et boolean array igen og dels at vi opnår en hastighedsforøgelse da der skal sorteres og betragtes færre k-mers. Yderligere betyder det at den første sekvens vil fremstå som reference for alignment en. At resultatet stadig vil være det samme kommer af at en MUM som indeholder en k-mer i reverse-komplementet i første sekvens, medfører at der også findes en MUM som er reverse-komplementet af den først beskrevne MUM. Sekvensdata tager nu lidt længere tid at tilgå, da vi benytter CLC s Sequence datatype (beskrevet i afsnit 4.1.3). Af denne grund prøver vi at genbruge diverse buffers med sekvensdata i det omfang det er muligt. Vi sørger for at sammenligne k-mers fra to sekvenser så længe det er muligt, hvilket vil sige ind til der er et match mellem to og dermed skal de øvrige også betragtes. Dette betyder at for hver sammenligning kan vi altid genbruge en ud af to buffere med sekvensdata. Håndtering af overlaps mellem MUM s Eliminering af overlaps mellem MUM s er grundlæggende det samme som i Prototypen (afsnit 3.1.2), dog med den forskel at reverse-komplementet giver anledning

50 4.3. GRUPPERING AF MUM S I KOLINÆRE BLOKKE 45 til at to MUM s også kan indeholde den samme nukleotid i reverse-retning. I alt kan en nukleotid altså være indeholdt i fire MUM s (se figur 2.7). Når MUM s sorteres efter deres placering i en sekvens ad gangen igen, så er det derfor tilstrækkeligt at huske på de to forrige MUM s i forward og reverse retningen. Det kan effektiviseres til at huske på de tre forrige MUM s uanset orientering. Såfremt de tre forrige MUM s ikke er orienteret som nødvendigt for tilfældet med maksimalt overlap, så vil færre end tre MUM s kunne overlappe og dermed er der ingen problemer med at håndtere overlappet. 4.3 Gruppering af MUM s i kolinære blokke Set i forhold til afsnit 3.2 så er fremgangsmåden hvorpå MUM s grupperes og fjernes den samme. Igen er der dog mere som skal tages højde for da MUM s i reversekomplementet giver anledning til flere tilfælde hvor breakpoints opstår. Vi følger derfor de tilfælde som fremgår af Mauveartiklen (afsnit 2.6.1), der kort fortalt tager højde for om nummereringen af MUM s i reverse-komplementet er faldende og om der forekommer skift i orienteringen mellem MUM s. Ud fra disse regler for hvornår to MUM s, (M 1, M 2 ), ikke er kolinære, har vi identificeret følgende to tilfælde for hvordan breakpoints reelt foretages. Hvis M 1 er orienteret i forward retningen noteres M 1.label. Hvis M 2 er orienteret i backward retningen noteres M 2.label. Det at et breakpoint noteres betyder her at vi husker M i.label i en liste, frem for som et field på M 1, som tidligere, hvilket sparer hukommelse. Disse to regler sørger for at notere de MUM s hvorefter der forekommer et breakpoint, set i forhold til orienteringen af MUM s i den første sekvens. Figur 4.5 viser et eksempel på hvordan ovenstående regler sørger for at breakpoints bliver identificeret. Kigges der på hvordan de illustrerede breakpoints identificeres så ses først (M 1, M 4 ) i Sek 2. Her ses det at orienteringen er forskellig og jævnfør vores to regler skal der noteres et breakpoint for M 1 og M 4. Breakpointet for M 3 kommer når (M 3, M 5 ) betragtes. Set i forhold til Prototypen (afsnit 3.2) så har vi på nuværende tidspunkt valgt en simplere løsning. Fremgangsmåden består derfor i, at MUM s indeholdt i de mindste LCB er, fjernes iterativt. Efterfølgende genberegnes alle LCB er. Løsningen med blot at fjerne LCB er og hvis muligt sammenflette de omkringliggende LCB er, er udeladt og kan senere benyttes såfremt tiden brugt på LCB er vurderes at være for stor.

51 46 KAPITEL 4. UDVIKLING AF DRAFT ÇÈÉÊ Ì Í Î Ï Ð ÇÈÉË Ì Í Î Ï Ð Figur 4.5: Her ses et eksempel med to sekvenser som indeholder fem MUM s. Breakpoints er illustreret som en stiplet linie i den første sekvens da det er i forhold til rækkefølgende heri at breakpoints giver mening. 4.4 Iterativ ankersøgning Vi har tilføjet en iterativ fase med udgangspunkt i Mauves fremgangsmåde beskrevet i afsnit Her forsøger vi at identificere ankre i områderne mellem LCB er og inden i LCB er med en mindre k-mer størrelse, gennem de såkaldte intern og ekstern ankersøgninger. Hvordan der præcist itereres over disse to metoder fremgår ikke af artiklen men vi vælger at starte med ekstern ankersøgning, så foretage intern ankersøgning for derefter at evaluere hvilke nye LCB er dette føre til og om der er sket en forbedring. Såfremt der er sket en forbedring foretages endnu en iteration Ekstern ankersøgning Mauve bruger en konceptuel konkatenering af områderne mellem LCB er og søger efter k-mers i denne nye sekvens. Vi laver ikke den konceptuelle konkatenering, men kigger blot på områderne mellem LCB er. Vi har valgt at lave denne simplificering, da der ligger en del ekstra arbejde i at skulle holde styr på en konceptuel konkatenering, og samtidig er eneste ulempe at vi kan overse de k-mers, der bliver delt af en LCB Intern ankersøgning Vi søger efter ankre internt i en LCB ved at kalde seed-and-extend fasen for hvert område mellem MUM s. Disse områder er illustreret på figur 4.6. Vi følger derfor Mauves metode med den forskel at vi paralleliserer algoritmen for hver LCB vi gennemsøger.

52 4.5. GAPPED ALIGNMENT 47 ÑÒÓÔ ÜÝÞØ ÜÝÞÙ Ö ÖØ Ö ÖÙ Ö ÖÚ Ö ÖÛ ÑÒÓÕ ÜÝÞØ Ö ÖØ Ö ÖÙ Ö ÖÚ ÜÝÞÙ ÜÝÞÛ Figur 4.6: Illustration af intern ankersøgning. Der er med gult markeret det område der søges i for nye ankre. Det kan ses at LCB 1 på dette tidspunkt udgøres af tre MUM s. 4.5 Gapped alignment Målet for dette sidste trin er som i afsnit 3.3 for Prototypen, at lave en alignment for de områder i LCB erne, der ikke er dækket af MUM s. Der er nu den forskel at LCB er ikke allerede er blevet splittet op i en tidligere fase, som i Prototypen, hvilket gør at vi kan have meget store afstande mellem MUM s. For at undgå problemer, gennemløbes alle LCB er, for at se om det er nødvendigt at splitte dem op. Grænsen for hvornår en LCB bliver splittet op er den samme som for Prototypen. Til sidst skal afstande mellem MUM s alignes, hvilket stadig gøres ved brug af det eksterne program Muscle. Vi har ikke tænkt os at optimere på hvordan der hurtigt kan kommunikeres med Muscle, idet dette kan udelades fra tests og vil være mindre interessant rent algoritmisk. På trods at dette så har vi for en type af en triviel alignment sørget for at Muscle ikke benyttes, som en optimering. Dette drejer sig om alignments af længde én. Vi har gjort det muligt parallelt at kalde eksterne alignmentprogrammer således at flere kerner bedre kan udnyttes. Dette indeholder dog en lidt uforudsigelig opførsel hvad angår hukommelsesforbruget og det kan være svært at undgå en instans af et eksternt program løber tør. Dette kan omgås ved blot at gentage den pågældende alignment såfremt det sker, men kan spilde en del tid. Vi har klargjort en struktur for kald af eksterne programmer, der nemt muliggører et skift til andre programmer og andre kommunikationskanaler, frem for at binde os til brug af disken. Ligeledes er det muligt at generere inputtet til alignmentprogrammet i flere formater, og ikke kun i fasta-format. Vi har desuden indbygget en alternativ fremgangsmåde til gapped alignment, som ikke indsætter nogle gaps. Dette kan være interessant, hvis man kun ønsker start og slut for hver LCB, og således ikke har brug for en detaljeret alignment af hver LCB. Herved undgås de mange eksterne kald og udførelsestiden kan afkortes. Vi har valgt ikke at forsøge at gøre gapped alignment fasen mere effektiv ud over parallelisering Problemet er ikke interessant algoritmisk, og kan muligvis løses ved at lave et effektivt multiple alignment værktøj i Java til små alignments og kun

53 48 KAPITEL 4. UDVIKLING AF DRAFT UML Diagram over vores integration med CLC s framework Figur 4.7: De klasser og interfaces på denne figur der er farvet blå, er en del af CLC s framework. De gule er dem vi selv har oprettet. Der er kun medtaget en delmængde af metoder og fields for at bevare overskueligheden og samtidigt fremhæve de væsentlige, for integration med CLC s Workbench. En alignment over flere sekvenser består af et GlobalAlignment objekt. GlobalAlignment indeholder en liste over AlignedLCB objekter der hver repræsenterer en LCB. Hver AlignedLCB har et array med en indgang for hver sekvens som indeholder en ShiftedAlignedSequenceData. ShiftedAlignedSequenceData beskriver et offset, en retning og hvor gaps er placeret via PackedAlignedSequenceData. Alle disse nævnte klasser implementerer ClcObjectReplaceable og udvider AbstractClcObject hvilket sikre at en alignment kan håndteres af CLC s Workbench. De samme klasser har også en tilsvarende klasse kaldet Value som suffix der repræsenterer de data, som hver klasse indeholder.

54 4.6. EVALUERING AF DRAFT 49 benytte et eksternt program for at foretage store alignments. For at sikre vores endelige alignment bedre kan benyttes i CLC bio s Workbench, så ønsker vi et kompakt internt format. Et UML klassediagram over hvordan en GlobalAlignment repræsenteres fremgår af figur 4.7. Det forholdsvis store antal klasser skyldes at en GlobalAlignment og de indeholdte klasser alle nedarver fra CLCObject som er standard objektet i CLC s Workbench. Ydermere for at de kan serialiseres og persisteres er det nødvendigt at have en klasse med de samme variabler men uden metoder, da det er modellen i CLC frameworket. Disse klasser gør objekter i CLC s Workbench uafhængige af placeringen på den tilhørende klasse med den reelle funktionalitet. De sikre også at der nemmere kan haves flere versioner af dataobjekter, såfremt senere ændringer er nødvendige. 4.6 Evaluering af Draft Evalueringen sker efter samme metode som vi har benyttet for Prototypen i afsnit 3.4. Eftersom vi for Draft en har haft en målsætning om øget parallelisering og mulighed for håndtering af større sekvenser, har vi medtaget nogle yderligere målinger for disse aspekter. Igen fremgår detaljer om evalueringen af hvert aspekt af kapitel Kvalitet og korrekthed For Draftversionen har vi lagt os mere fast på strukturen af implementeringen. Dette har gjort at det giver mere mening lave en lang række unit tests. Disse tests er målrettet mod enkelte elementære funktioner. En stor del af disse tests sørger for at måle de mange nye situationer der opstår, når reverse-komplementet også betragtes. Ellers sørges der for at teste forskellige grænsetilfælde hvilket netop er nogle af de fejl som ikke altid opdages ved test på mindre datasæt. Den største gevinst af disse unit tests forventes at komme når vi begynder at optimere på implementeringen af Final i kapitel 5. Det at evaluere kvaliteten af den endelige alignment, er også et udtryk for korrekthed i et vidst omfang. Forudsat at der produceres et gyldigt output, så vil kvaliteten nemlig også falde, såfremt der eksempelvis sorteres forkerte data fra eller der fejlagtigt påstås, at visse områder hører sammen. Som for Prototypen har vi foretaget en visualisering af en alignment af datasættet for 3 bakterie genomer (3bac). Figur 4.8 indeholder denne visualisering og viser en stor overensstemmelse sammenlignet med Mauve 1.2 på figur 4.9. En mere præcis måling af kvaliteten ser ud som følgende:

55 50 KAPITEL 4. UDVIKLING AF DRAFT Prototype Draft Mauve 1.2 Sensitivity 0,6096 0,9205 0,9300 PPV 0,9985 0,9989 0,9983 Vi har også udviklet en sekvenssimulator, hvorom detaljer fremgår af afsnit 6.7, med det formål at kende en korrekt alignment. Kvaliteten for datasættet af tre simulerede bakterie genomer af 4.5 mega basepar (3bsim5), fremgår af følgende tabel: Prototype Draft Mauve 1.2 Sensitivity 0,7106 0,9633 0,9612 PPV 0,9985 0,9982 0, NC_ fasta (no annotations loaded) NC_ fasta (no annotations loaded) NC_ fasta (no annotations loaded) Figur 4.8: Denne illustration viser en alignment lavet af Draft for tre bakterie genomer NC_ fasta (no annotations loaded) NC_ fasta (no annotations loaded) NC_ fasta (no annotations loaded) Figur 4.9: Tilsvarende alignment som på figur 4.8 lavet med Mauve 1.2.

56 4.6. EVALUERING AF DRAFT 51 Det ses generelt at Draftversionen klarer sig betydeligt bedre end Prototypen, da sensitivity er steget kraftigt. Dette var også forventeligt da reverse-komplementet medtages. Det kan også bemærkes at det ikke har givet anledning til flere falskpositive da PPV stort set er uændret. Sammenlignes Draft med Mauve 1.2 ses det at sensitivity er tæt på at være ens, dog med en mindre forskel ved datasættet for de tre bakterier. Denne forskel kan enten tolkes som at Mauve 1.2 enten klare sig lidt bedre for netop denne type data, eller da det er der Progressive Mauve der bruges som reference, at Mauve 1.2 blot har flere fællestræk med denne metode. Vi konkluderer derfor at vores Draft producerer alignments af en kvalitet meget lig Mauve 1.2 for disse datasæt. Dette var også hvad målet var og understreger blot at de væsentlige funktioner af Mauve 1.2 fremgår klart af Mauveartiklen [5] og at vi har forstået og realiseret disse korrekt Hukommelsesforbrug Draftversionen har forsøgt at minimere hukommelsesforbruget i forhold til Prototypen. Figur 4.10 viser hvordan det forholder sig for datasættet 3bac. Først ses det at hukommelsesforbruget er betydeligt mindre for Draft end for Prototypen. Når forholdet mellem disse to vurderes skal det huskes at reverse-komplementet medtages, hvilket giver en fordobling i antal af k-mers som skal betragtes. Det ses dog at sammenlignet med Mauve 1.2 bruger vi stadig væsentlig mere hukommelse. En graf der viser detaljerne for hukommelsesforbruget af Mauve 1.2 fremgår af bilag B.1.1 og denne viser at seed-and-extend fasen bruger omkring 10MB hukommelse. Dette er meget lavt taget i betragtning af at der analyseres tre sekvenser der hver indeholder 5 mio. nukleotider og der sorteres et tilsvarende antal k-mers. Om Mauve 1.2 benytter komprimering af disse data eller benytter harddisken er svært at sige. Draftversionen har mulighed for at benytte harddisken i det omfang det er nødvendigt. Grundet betydeligt større hukommelsesforbrug end Mauve 1.2, kan det blive nødvendigt at bruge disken før denne, ved større sekvenser. Derfor udgør dette et potentielt ydelsesmæssigt problem. Det at anvende Java og benytte CLC bio s framework var forventet at kunne lede til et større hukommelsesforbrug, og dette er også hvad vi har observeret. Derfor er seed-and-extend fasen stadig interessant at kigge på i næste iteration for implementeringen af Finaludgaven i kapitel Tidsforbrug Den øverste graf på figur 4.11 viser tidsmålinger for Draft. Datasæt og målinger er som for Prototypen i afsnit Det ses at Draftudgaven stadig ikke kan matche Mauve 1.2 med hensyn til samlet udførelsestid, men at der er sket forbedringer sammenlignet med Prototypen.

57 52 KAPITEL 4. UDVIKLING AF DRAFT Hukommelsesforbrug over tid for Prototype, Draft og Mauve 1.2 Prototype-noalign Draft-noalign Mauve-1.2-noalign Hukommelse [mb] Tid [s] Figur 4.10: Hukommelsesforbruget for Draft sammenlignet med Prototypen og Mauve 1.2. For at undersøge udførelsestiden lidt mere detaljeret og den del af algoritmen vi står for, dvs. foruden kald af eksternt alignment program, så kan der kigges på den nederste graf på figur Her ses at vores implementering er langsommere end Prototypen samt Mauve 1.2. Igen som i afsnittet om hukommelsesforbrug skal der huskes på at reverse-komplementet er taget med. Ydermere foretages der iterativ forbedring af de fundne LCB er, hvilket også tager ekstra tid. Tages disse to ekstra tilføjelser i betragtning, er der stadig er sket forbedringer i forhold til Prototypen. Der ses en del udsving for Draft. Disse er forårsaget af at antal iterationer i den iterative raffinering af LCB er varierer. Samlet set viser de to grafer fra figur 4.11 at inklusiv paralleliseringen af eksternt alignmentprogram, har vi opnået en forbedring af udførelsestiden fra Prototype til Draft. Vi vil i de næste to underafsnit undersøge nærmere i hvilket omfang det er lykkedes os at parallelisere algoritmen samt hvordan udførelsestid opfører sig for større sekvenser Parallelisering Som det fremgik af forrige afsnit så er Mauve 1.2 hurtigere end vores Draft for det konkrete datasæt. Derfor tester vi i dette afsnit hvordan vores parallelisering af

58 4.6. EVALUERING AF DRAFT Tidsforbrug for Prototype, Draft og Mauve 1.2 Draft Prototype Mauve Tid (sek) Laengde (mbp) Tidsforbrug for Prototype, Draft og Mauve 1.2 uden endelig alignment Draft-noalign Prototype Mauve-1.2-noalign 250 Tid (sek) Laengde (mbp) Figur 4.11: Øverste graf viser samlet tidsforbrug for Draft udgaven, den tidligere Prototype og Mauve 1.2. Nederste graf viser tidsforbruget hvor gapped alignment fasen er udeladt.

59 54 KAPITEL 4. UDVIKLING AF DRAFT Tidsforbrug for Draft og Mauve 1.2 ved et forskelligt antal af sekvenser Draft Mauve Tid (sek) Antal sekvenser CPU udnyttelse for Draft og Mauve 1.2 ved et forskelligt antal af sekvenser Draft Mauve CPU Forbrug i procent Antal sekvenser Figur 4.12: Øverste graf viser tidsforbrug inklusiv alignment med Muscle. Nederst ses CPU-forbruget hvor 400% er maksimal udnyttelse på den anvendte 4-kernede maskine.

60 4.6. EVALUERING AF DRAFT 55 Datasæt id Størrelse på datasæt [MB] Tid for Draft [s] Tid for Mauve 1.2 [s] Forhold mellem tid for Draft og Mauve 2mam ,77 2mam ,59 2mam ,70 2mam ,87 Tabel 4.1: Udførelsestiden som funktion af sekvenslængden for Draft og Mauve 1.2. Det ses at der er en forholdsvis kraftig stigning men at forholdet mellem de to metoder ikke ændre sig væsentligt. seed-and-extend, raffinering af LCB er og kald af Muscle opfører sig. Dette gør vi ved at variere antallet af sekvenser. Det konkrete datasæt betegner vi 6bsim3. Resultatet kan ses af figur 4.12 og viser at vores Draft klart har en fordel med hensyn til skalering af flere sekvenser. På den benyttede 4-kernet maskine opnås bedst CPUudnyttelse ved 5 tråde. Herefter stiger overhead ved at køre tråde uden der opnås bedre CPU udnyttelse. Det at vi ikke udnytter alle fire kerner fuldt ud kommer dels af at Draft stadig ikke er fuldt paralleliseret og dels at de fleste data ligger i CLC s cache hvor adgang er synkroniseret og dermed enkelttrådet Håndtering af store sekvenser For Draft udgaven har vi fokuseret på at få hele Mauvealgoritmen implementeret og få den til at skalere i forhold til antallet af sekvenser. Vi har derimod ikke lagt så meget vægt på hvorvidt den skalerer til længere sekvenser. Dette undersøger vi nærmere i dette afsnit. Vi har taget udgangspunkt i sekvenser af forskellige længder mellem 6 MB og 26 MB. Først har vi set på hvor godt vi klare os sammenlignet med Mauve 1.2, hvilket fremgår af tabel 4.1, der viser udførelsestiden uden endelig alignment. Det ses af tabellen at udførelsestiden stiger markant som længden forøges. Det er værd at bemærke at forholdet mellem Draft og Mauve 1.2 ikke ændre sig væsentligt. Undersøges udviklingen for Draft nærmere ses det at der tale om en kvadratisk udvikling som funktion af sekvenslængden, hvilket ikke er optimalt ifølge teorien i afsnit Figur 4.13 viser hvordan hver enkelt trin skalerer. Heraf ses det tydeligt at det største problem er Greedy Breakpoint Elimination. Da det var lidt uventet at Greedy Breakpoint Elimination brugte så meget tid ved store sekvenser, undersøgte vi dette nærmere i overgangen mellem Draft og Final. Her viste det sig at den ekstra tid blev brugt på at fjerne MUM s, for de LCB er der blev sorteret fra, ved hver iteration. Den kvadratiske udførelsestiden kom af at der blev lavet et fuldt gennemløb af listen over MUM s der skulle fjernes for hver eneste oprindelige MUM. Dette skete som resultat af et kald til Java s removeall(...).

61 56 KAPITEL 4. UDVIKLING AF DRAFT èéê ëìéíî äçß äãß ãæß ãåß ãäß âß áß Udførelsestiden fordelt på de forskellige faser ved forskellige sekvenslængder ùúûüýú þúÿüý ú ú ÿûüýú þúÿüý ú ú ýüü ýüþÿ úû ü úþû ú üü þú ü ûüú àß ß á ãç äß äá ïðñòðíóôõíöêð ë øî Figur 4.13: Udførelsestiden som funktion af sekvenslængde. Det ses at specielt Greedy Breakpoint Elimination skalerer dårligt. Dette løste vi simpelt ved at udskifte listen over MUM s der skulle fjernes med en hashtabel. Dette reducerede tidsforbruget til en størrelsesorden der næsten er uden betydning sammenlignet med de øvrige. Denne rettelse er taget med her, da den viser hvordan, for implementeringen af en metode der håndterer store datasæt, en sådan fejl kan have omfattende konsekvenser. Resultater efter denne rettelse fremgår af figur 4.14 og viser generelt at alle faser bruger en forholds lige del af udførelsestiden hvis Greedy Breakpoint Elimination ikke medregnes Erfaringer Vi har i Draft udgaven set at det er muligt at implementere en udgave af Mauve i Java uden at udførelsestiden stiger markant. Dette blev gjort ved brug af CLC bio s framework og har resulteret i et plugin til CLC Workbench. Kvaliteten er nogenlunde på niveau med Mauve 1.2. Integrationen i CLC Workbench er som ønsket og fokus i Final kan derfor primært være på optimering af udførelsestiden. I forbindelse med målinger af hukommelsesforbruget og parallelisering af algoritmen, har vi identificeret seed-and-extend fasen som et oplagt mål for en videre udvikling. Seed-and-extend fasen kunne eksempelvis ikke paralleliseres til flere kerner/cpu er end antal sekvenser der alignes. Vores overordnede mål for Finaludgaven af vores algoritme er følgende: Kig nærmere på første fase til at finde ankre, med henblik på minimering af

62 4.6. EVALUERING AF DRAFT 57 ()*+,) -).+,/01)2)1 3./*+,) -).+,/01)2)1 4,++56 7,+-.892)* +:2;2)-*29) <++5=-)5=+>*+)5!"#$% &' Figur 4.14: Udførelsestiden som funktion af sekvenslængde med optimeret Greedy Breakpoint Elimination. hukommelsesforbrug og bedre parallelisering. Forsøg at optimere senere faser således at algoritmen er bedre rustet til store sekvenser.

63

64 K A P I T E L 5 UDVIKLING AF FINAL Efter at have lavet en implementering, der følger Mauve forholdsvis nøje, vil vi i dette kapitel forsøge at eksperimentere med at forbedre udførelseshastigheden, hukommelsesforbruget samt i et vidst omfang kvaliteten for alignments. Dette kapitel er inddelt i tre større afsnit. Hvert af disse har forskellige formål og derfor motiveres og evalueres de selvstændigt. En samlet evaluering for Final er udskudt til kapitel 6. Dette er gjort, fremfor i afslutningen af dette kapitel, da vi ønsker at foretage en bredere sammenligning af vores Finaludgave med andre lignende programmer. Første afsnit ser på en alternativ algoritme, kaldet Pash [12], der er en algoritme til effektiv parallel bestemmelse af ankre for to sekvenser. Med afsæt i denne algoritme, vil vi forsøge at lave en alternativ udgave af den indledende ankersøgning, med det formål at begrænse pladsforbruget og øge paralleliseringen. Det efterfølgende afsnit omhandler et eksperiment, der har til formål at se hvor meget vi kan forbedre kvaliteten af vores alignment, ved at inkludere MUM s, der kun findes i en delmængde af sekvenserne. Eftersom dette er en gennemgribende ændring, der påvirker alle faser i vores algoritme, er vores formål primært at få indblik i de udfordringer, der opstår og potentiale for forbedring af kvaliteten, fremfor at inkludere dette i vores endelige implementering. I sidste afsnit kigges der på en række optimeringer, vi selv har udviklet, som skal ruste vores algoritme til at håndtere store sekvenser. Hver af disse optimeringer diskuteres og evalueres selvstændigt, for tydeligt at kunne se konsekvensen af hver enkelt ændring. Der er tale om følgende optimeringer: Forbedring af fletning af lister over k-mers. 59

65 60 KAPITEL 5. UDVIKLING AF FINAL Bedre detektion af MUM s. Undgå genberegning af LCB er ved hver iteration. Detektion af hvilke LCB er, der ikke behøves gennemsøgt for interne ankre efter flere iterationer. Ændring af alignment strategi, for områder uden ankre i LCB er. 5.1 Pash Pash[12] (Positional Hashing) er en algoritme, der er lavet til effektivt, at kunne sammenligne to store sekvenser med hinanden, fordelt på flere maskiner. Disse to sekvenser betegnes i dette afsnit som S og T. Resultatet findes, ligeledes seed-andextend algoritmen, ved at identificere ankre mellem de to sekvenser, med udgangspunkt i k-mers. Dog er ankrene i Pash ikke garanteret til at være globalt unikke, og kan således ikke betegnes MUM s. Pash er en ny algoritme, som ikke tidligere er omtalt, og derfor introducerer vi den bagvedliggende teori i dette afsnit. Herefter gennemgås de ændringer, vi har foretaget, for at kunne bruge Pash som del af vores algoritme. Pash adskiller sig hovedsageligt fra seed-and-extend ved at splitte alignmentproblemet op i mindre delproblemer, hvor hvert delproblem betegnes som en diagonal. Hver diagonal kan løses sekventielt eller parallelt på en eller flere computere. Ud over at parallelisere alignmentproblemet, tilbyder Pash muligheden for, at lave en afvejning mellem hastighed og kvalitet Pash algoritmen Algoritmen opsplitter alignment-problemet ud fra en brugerdefineret værdi L, der angiver antallet af diagonaler. Hver diagonal bearbejder T L forskydninger af sekvens T, sammenholdt med sekvens S. De skrå streger på del (B) af figur 5.1, viser de forskydninger af T, en diagonal kan betragte. Ved at have en forholdsvis lille værdi for L, betragtes mange forskydninger af T i den samme diagonal, og herved spares tid, da der er færre diagonaler, der gennemløber sekvenserne. Omvendt kan problemet deles yderligere op, for en større værdi af L, og derved fordeles på flere maskiner, samt bruge mindre hukommelse på hver af disse. Pashalgoritmen er beskrevet i algoritme 1. For at Pash betragter samtlige k-mers for begge sekvenser, skal antallet af diagonaler L være mindst 2 k. Vælges en mindre værdi for L, vil T ikke blive forskudt k gange, hvilket vil svare til at se helt bort fra en række af diagonaler i et dot-plot. Ved høj similaritet, som angiver hvor stor en andel af nukleotiderne, der er identiske mellem sekvenserne, er det uden stor omkostning, at springe nogle af iteratio-

66 5.1. PASH 61 Figur 5.1: Opdeling af alignment-problemet i diagonaler. Pash er effektiv til at parallelisere problemet for to sekvenser, da den for en diagonal betragter k-kmers, fundet i S, med k-mers, fundet med en bestemt forskydning i T (svarende til visuelt at se på et antal diagonaler i et dot-plot). På figuren er sekvens S betegnet Genome 1 og T er betegnet Genome 2. (A) Skitserer alle forskydninger af S på T. (B) Viser opdelingen i diagonaler, hvor hver diagonal ser på en delmængde af forskydningerne. (C) Viser med tykke streger, hvilke dele af S og T, der kommer i samme hashtabel, for hver iteration i en diagonal. Figuren er lånt fra [12].? A ACD EFD ECA ECACD GEFD ACH ACHCD ECACH ECACHCD B Figur 5.2: Pashdiagonal d med følgende parametre: iterationsnummer j, k-mer længde k og antal diagonaler L. De markerede områder viser de k-mers, der kommer i samme hashtabel. Jo tættere L er på k, desto flere elementer er der i samme hashtabel, og der er derfor brug for færre diagonaler.

67 62 KAPITEL 5. UDVIKLING AF FINAL Algorithm 1 Pashalgoritmen, som beskrevet i [12]. Opdeling af en alignment over sekvenserne S og T i diagonaler, ud fra diagonalstørrelsen L (se figur 5.1). Diagonaler fordeles på det tilgængelige antal af maskiner. For hver maskine, bearbejdes diagonalerne sekventielt. For hver diagonal d, sammenlignes S og et antal forskydninger af T. Figur 5.2 viser de dele, der sammenlignes for en given diagonal og iteration. Konceptuelt svarer j variablen til at flytte startpositionen for en k-mer hen over både T og S. Ved at springe nogle af iterationerne for j over, kan man derved reducere tidsforbruget på bekostning af sensitiviteten. Dog kan der højst springes over k 1 iterationer ad gangen, da k-mers ellers ikke kan grupperes. For hver iteration j = 0,..., L k i en diagonal d, haves der en hashtabel H d, hvor j og j + d angiver relative startpositioner i henholdsvis S j,j+d og T. Hver hashtabel udfyldes med k-mers, defineret ved delstrengene S[i L+ j...i L+ j + k] for i = 0,..., S L. Nu indsættes der efterfølgende i H d for j = 0,...,L k efter k-mers, j,j+d givet ved T [i L+ j + d...i L+ j + d+ k] for i = 0,..., T L. For hver diagonal, er det muligt at udelade nogle af de j iterationer, for at forøge hastigheden, men på bekostning af sensitiviteten. Hashtabellerne inverteres, hvilket vil sige at der kigges på de indgange, hvor der er et match mellem en k-mer i S og T. Dette bruges til at opbygge ankre af sammenkædede k-mers. Eftersom hashtabellerne er indekseret efter startoffset i k-mers, er ingen sortering nødvendig. Resultater fra alle diagonaler indsamles og der køres et filter, der ud fra en signifikansscore af ankrene, forsøger at fjerne falsk-positive ankre. Algoritmen er nu færdig. nerne i hver diagonal over, da man stadig har nok information til at kæde k-mers sammen. Ved lavere similaritet, vil der dog være en del ankre, der enten bliver kortere eller slet ikke fundet, grundet de manglende k-mers. Udførelsestiden samt hukommelsesforbruget for Pash er O(( S + T ) L), under forudsætning af at outputtet har størrelse på O( S + T ). Hvis outputtet er større, ved fx en repetitiv sekvens, hvor en k-mer i sekvens S, kan afbildes over i mange i T, kan udførelsestiden blive O(( S T ) L) [12]. Under antagelse om, output størrelse på O( S + T ) og at der er mulighed for at parallelisere algoritmen på L maskiner, bliver udførelsestiden altså reduceret til O( S + T ). Man ville normalt forvente, at når hver diagonal betragter færre forskydninger af T, vil det give en kortere udførelsestid for hver diagonal. Dette er i midlertidig ikke tilfældet, da en diagonal tager den samme tid, uanset det samlede antal af dia-

68 5.1. PASH 63 gonaler L. Dette skyldes at antallet af sammenligner for at sammenligne alle k-mers mellem S og T stiger kraftigt, når L forøges. Når problemet bliver delt yderligere op, indeholder hver hashtabel, et færre antal k-mers, og således er det nødvendigt at foretage mange flere iterationer, for at foretage det samme antal sammenligninger. Hvis L (antallet af diagonaler) fordobles, skal hver diagonal d indeholde dobbelt så mange hashtabeller (af halv størrelse), for at lave det samme antal sammenligninger. Dette kan illustreres med følgende eksempel: Hashtabel, hvor følgende elementer insættes, for at sammenligne fire k-mers: S: ACTGA CTGGT T: ACTAC GTTGG Hvis der kun indsættes to k-mers i hver hashtabel, kræves der nu fire gange så mange hashtabeller og samlet set dobbelt så mange indsættelser, for at lave samme sammenligning. En lodret streg angiver, at der bruges en ny hashtabel. S: ACTGA S: ACTGA S: CTGGT S: CTGGT T: ACTGA T: GTTGG T: ACTAC T: GTTGG Det ses at når antallet af diagonaler L fordobles, laves en tilsvarende forøgelse i det samlede antal af indsættelser. Altså tager hver diagonal den samme tid, uanset L. Konsekvensen af dette er, at der altid bør vælges en så lille værdi for L som muligt, givet mængden af hukommelse på de maskiner, der skal køre algoritmen. I næste afsnit beskriver vi vores implementering af Pashalgoritmen Implementering af Pash For at implementere Pash, har vi taget udgangspunkt i overstående algoritme. Vi har dog først været nødsaget til at lave en række af tilpasninger af Pashalgoritmen således, at den egner sig til brug i vores algoritme. Pash kan i praksis bruges til både den indledende ankersøgning, samt den interne og eksterne ankersøgning, men eftersom vi ikke på forhånd vidste, hvorvidt algoritmen var fordelagtig, har vi valgt at begrænse os til at fokusere på den indledende ankersøgning. Tilpasning af Pash I forbindelse med vores algoritme, er vi interesseret i at lade paralleliseringen foregå på en maskine med flere kerner, og vi kan således se bort fra netværks perspektivet. Eftersom vi i vores implementering er mindre interesseret i dubletter af k-mers, har vi valgt at se bort fra dem, der kan forekommer i samme hashtabellerne undervejs i hver diagonal. Vi bruger en hashfunktion, der gør at identiske k-mers får samme værdi, og vi kan således blot kassere de indgange, der giver anledning til duplikater.

69 64 KAPITEL 5. UDVIKLING AF FINAL Vores hashfunktion laver en tal-repræsentation af en k-mer, baseret på dens nukleotider og rækkefølgen af disse, således at der kun findes netop én hashværdi for en given sammensætning af nukleotider af længde k. Eftersom k-mers består af nukleotidalfabetet: A, C, T og G, kan hashfunktionen pakke k-mers effektivt, således at der ikke spildes plads. Et eksempel på hashfunktionen kan ses herunder: k-mer: ACTGAACCTGACCTG (15 byte) Oversættelse. A->00 C->01 T->10 G->11 Binær: Integer (4 byte)/long(8 byte): Hashfunktionen er effektiv, så længe den bruges på k-mers, der har en længde mindre end Java s long-datatype på 8 byte, svarende til en k-mer-længde på 32. Ifølge formlen for k-mer-størrelsen i Mauveartiklen (beskrevet i kapitel 2.8) svarer dette til en optimal k-mer-længde for sekvenser på 4 milliarder basepar, hvilket er mere end nødvendigt, for at aligne to kromosomer med hinanden. Pash kan godt klare en større k-mer-længde, men dette betyder at den mindre effektive datatype BigInteger vil blive benyttet. Der er ingen understøttelse for håndtering af reverse-komplementet i Pash. Den simpleste udvidelse ville være, blot at køre Pash med S og T, samt S og reversekomplementet af sekvens T. Dette vil dog betyde, at udførelsestiden fordobles, og vi har i stedet valgt, at lade en diagonal indeholde sekvens T både i forward og i reverse-komplement. Således spares et gennemløb af S sekvensen for hver diagonal. Vi har ikke tænkt os at udvide Pash til, at understøtte mere end to sekvenser, da dette vil kræve en del mere arbejde, uden at vi på forhånd ved om brugen af Pash til den indledende ankersøgning er mere fordelagtig for vores implementering end seed-and-extend. Vi har dog overvejet to måder, hvorpå dette kan gøres: Den første er at sammenligne én sekvens med alle de andre, hvor man først identificerer de dele, der matcher mellem en bestemt sekvens og alle andre sekvenser. Det man ønsker er så fællesmængden af disse ankre, for hver af disse sammenligninger. Dette kræver, at Pash køres et antal gange, der er proportional med antallet af sekvenser. En anden fremgangsmåde ville være den, som Progressive Mauve benytter, beskrevet i afsnit Her laves der parvise sammenligner mellem alle muligheder. Dette giver muligheden for at finde ankre mellem delmængder af sekvenserne. Caching mellem diagonaler Det kan observeres fra afsnit 5.1.1, at Pashalgoritmen for sekvens S udelukkende bruger j til at finde de steder, der skal indsættes i hashtabellen. Det vil sige, at diagonaler, der køres i parallel, genererer identiske hashtabeller. Dette udnytter vi til at lave en hastighedsoptimering. Da iterationerne i hver diagonal ikke kræver en be-

70 5.1. PASH 65 stemt rækkefølge, kan hver diagonal udregne forskellige iterationer samtidig, men i forskellig rækkefølge. Når en diagonal så har beregnet en iteration, kan den dele sit resultat med de andre diagonaler og herefter selv udnytte resultatet fra andre diagonaler. Ved at bruge dette system, kan der spares oprettelse af hashtabeller samt unødig hashing af S-sekvensen. Der introduceres dog en mulighed for at nogle af diagonalerne kommer til at skulle vente på hinanden. For at undgå dette, har vi tilladt at nogle af iterationerne kan fortsætte til beregningen af de næste iterationer, såfremt de ellers skal stå og vente på resultatet. For at realisere dette, har vi brugt Javas Executor-framework til at skedulere diagonalerne således, at et bestemt antal kører samtidigt. Herudover har vi selv lavet et særskilt caching-system, der håndterer, hvorvidt en diagonal skal udregne hashtabellen for en iteration eller genbruge et tidligere resultat. Når en iteration er blevet kørt lige så mange gange, som der er parallelle diagonaler, bliver de midlertidige data frigjort og loftet for hvilke iterationer, der kan beregnes, forøges. Caching-systemet bruges også til at implementere afvejningen mellem sensitivtet og hastighed. Caching-systemet kan styre hvilke iterationer der springes over i hver diagonal, ud fra en brugerdefineret parameter. Implementering af en diagonal For hver diagonal, bruger vi overstående caching-system til at forespørge hvilke iterationer, der skal køres. Hvis caching-systemet melder, at der ikke er mulighed for beregning af nogle data på nuværende tidspunkt, venter diagonalen og spørger så igen efter noget tid. Hver diagonal følger algoritme 1, med den undtagelse af at der fjernes duplikater for hver hashtabel i diagonalen. Desuden har vi tilføjet et filter til hver diagonal: Efter k-mers er kædet sammen til ankre, prøver vi at forbinde disse ankre, såfremt der kun er et relativt lille mellemrum mellem dem. Altså betragtes de omkringliggende ankre, og hvis der findes et par af ankre hvor mellemrummet mellem dem er betydeligt mindre end hver af disse ankre, kædes de sammen. Herefter tjekkes der om der findes mindre ankre der nu overlappes af det nye anker, og disse kan fjernes. Dette filter bevirker at de lange ankre favoriseres, hvilket er en fordel da de små ankre har større sandsynlighed for at være tilfældige matches. Persistering mellem diagonaler Når en diagonal er færdig, skrives resultat ud til disken i et komprimeret format. Dette gøres i en separat tråd, således at næste diagonal kan fortsætte, mens en separat tråd skriver. Dette bevirker at Pashalgoritmen ikke har et stigende hukommelsesforbrug, efterhånden som flere diagonaler bliver færdig.

71 66 KAPITEL 5. UDVIKLING AF FINAL Forskelle mellem seed-and-extend og vores udgave af Pash Pash betragter k-mers i diagonaler, hvor hver diagonal kun betragter en brøkdel af sekvenserne samtidig. Seed-and-extend betragter i stedet samtlige k-mers for de sekvenser, der skal sammenlignes. Altså giver Pash mulighed for at dele problemet op, således at der kun bruges den mængde hukommelse, der stilles til rådighed af maskinen. Seed-and-extend har den fordel, at den skalerer til sammenligning af flere end to sekvenser samtidig, hvor Pash algoritmen kræver flere separate kørsler, for at gøre det samme. Da Pash sammenligner k-mers i diagonaler, ikke kræver at k-mers er globalt unikke samt bruger et filter til at favorisere lange ankre, forventer vi, at den har mulighed for at klare sig godt på store sekvenser med lav similaritet. Dette skyldes, at den søger i diagonaler, hvor den forventes at undlade de steder, hvor der forekommer mange repeats, mens den kan medtage en del af de k-mers, der ikke er globalt unikke, men som stadig udgør en del af et anker mellem sekvenserne. Pash tilbyder desuden muligheden for, at lave en afvejning mellem sensitivitet og hastighed, hvilket kan gøre en stor forskel til den indledende ankersøgning. Her kan man således nøjes med at finde de længere ankre og derefter lade den efterfølgende raffineringsfase finde nye ankre Evaluering af Pash Der er mange aspekter, som kunne evalueres for Pash. Fokus i dette afsnit er på parametre, der er specifikke for Pash, så som variation af antal diagonaler, antal iterationer, der foretages per diagonal, og parallelisering. Hvordan Pash skalerer med hensyn til sekvenslængde og hvilken kvalitet der generelt opnås, evalueres samlet for Final med seed-and-extend i kapitel 6. Vi har i dette evaluerings afsnit, brugt nogle andre datasæt end hidtil. Dette skyldes at Pash kun virker på to sekvenser ad gangen, samt at vi gerne vil have resultater for større datasæt, hvor det er lettere at vurdere om Pash er fordelagtig. Forfatterne til Pashartiklen har valgt, ikke at frigive deres implementering. Vi har af denne grund ikke haft nogen reference at sammenholde vores implementering af Pash med. Hukommelsesforbrug For at evaluere hukommelsesforbruget, er Final med Pash og seed-and-extend blevet kørt på et 33 MB stort datasæt (2mam33). Figur 5.3 viser grafen for testen. Det ses af grafen, at Pash har et meget konstant hukommelsesforbrug gennem hele forløbet af Pashalgoritmen. Ved at køre to tråde fremfor én, fordobles det maksimale

72 5.1. PASH Hukommelsesforbruget over tid for Final og Final-Pash for en og to tråde Final-Pash-t1 Final-Pash-t2 Final-t1 Final-t2 700 Hukommelse [mb] Tid [procent af samlet tid] Figur 5.3: Hukommelsesforbruget for Pash (30 diagonaler) sammenlignet med seed-and-extend. t1 og t2 angiver, hvorvidt der er kørt med en eller to tråde. Efterfølgende intern og ekstern ankersøgning er udeladet fra denne test. hukommelsesforbrug, hvilket er som forventet, da to diagonaler bearbejdes samtidig, fremfor én. Hver diagonal i Pash bruger kun en brøkdel af den hukommelse seed-and-extend bruger, men set i lyset af, at Pash kun betragter 1 30 af sekvensen ad gangen, bruger den faktisk forholdsvis meget hukommelse. Det kan således godt blive et problem at udnytte alle kerner på en maskine, hvis mængden af hukommelse ikke matcher det antal af diagonaler der køres samtidig. Vi har også undersøgt, hvordan hukommelse og tidsforbrug er forbundet for et større datasæt. En test på et datasæt med kromosom X fra menneske og mus (2chrX) fremgår af følgende tabel. Ca. tid per Gennemsnitligt L diagonal [s] hukommelsesforbrug [MB] Det ses, at når antallet af diagonaler L fordobles, falder det samlede hukommelsesforbruget kun 17%, fremfor de 50%, man ville forvente, taget i betragtning af, at hver hashtabel kun har den halve størrelse. Dette har formentligt to årsager: Den

73 68 KAPITEL 5. UDVIKLING AF FINAL første er, at der er målt på det samlede hukommelsesforbrug, der ud over Pashdelen også indeholder en masse sekvensdata. Af denne grund kan hukommelsesforbruget for Pash godt være faldet 50%, mens det totale hukommelsesforbrug har et noget mindre fald. En anden medvirkende årsag kan være, at nogle data fra hver diagonal er gemt i CLC bio s cache, og således ikke automatisk bliver fjernet af Javas garbage-collection, når der er hukommelse nok til rådighed Caching af data mellem diagonaler Som nævnt i afsnit har vi lavet vores eget caching-system, der gør det muligt at spare nogle af udregningerne i de diagonaler, som køres parallelt. Vi har her prøvet at slå dette system fra og se, hvor stor en påvirkning det har på udførelsestiden. For følgende test er Pash kørt med 4 kerner på 2chrX. Tid for ankersøgning [s] 4 tråde med cache tråde uden cache 2742 Det ses, at caching-systemet har haft en meget positiv effekt på tidsforbruget, som er faldet med 43%. Dette skyldes, at hver diagonal kun har oprettet en fjerdedel af alle hashtabellerne, mens den har kunne genbruge de resterende tre fjerdedele. Afvejning mellem sensitivitet og hastighed Vi har kigget på både den totale tid og den tid Pash bruger som antallet af iterationer varieres, for hver diagonal. Dette har vi gjort, da resultatet af den indledende ankersøgning også kan få konsekvenser for hvordan raffineringsfasen, bestående af intern og ekstern ankersøgning, forløber. Resultatet fremgår af tabel 5.1. Kvaliteten ligger lidt højere for Pash end for seed-and-extend. Eftersom Pash ikke har et krav om globalt unikke ankre, er den bedre til at finde indledende ankre. De efterfølgende ankre i ekstern ankersøgning identificeres med seed-and-extend, og er altså stadig unikke indenfor området der gennemsøges, samt udvidet maksimalt til begge sider. Pash til ekstern ankersøgning Eftersom Pash har vist sig at være fordelagtig til den indledende ankersøgning, har vi også forsøgt at se resultatet, når den bruges til den eksterne ankersøgning. Netop denne fase udgør en stor del af udførelsestiden, og kan kun paralleliseres i antallet af sekvenser. Resultaterne har dog været meget blandede for brugen af Pash: Trods Pash i alle tilfælde bruger mindre tid på hver iteration, stiger antallet af iterationer

74 5.2. MUM S FOR DELMÆNGDER AF SEKVENSER 69 Antal iterationer [%] Ankersøgnings tid [s] Total tid[s] Sensitivitet PPV Seed-and-extend 428 (228%) (100%) (84%) (72%) (49%) Tabel 5.1: Sammenligning af udførelsestid og kvalitet for seed-and-extend og Pash på 33 mb datasæt(2mam33). For Pash varieres antallet af iterationer endvidere. kraftigt i nogle tilfælde og giver således en langsommere samlet udførelsestid. Nedenfor ses en tabel over et 45 MB datasæt (2mam45), der indeholder en del repetitive områder, hvor der kan ses at Pash til ekstern ankersøgning, ikke altid er fordelagtigt. Ankersøgnings metode Tid [s] Sensitivitet PPV Pash og Seed-and-extend Seed-and-extend Pash Pash Skip Det ses at Pash til både indledende og ekstern ankersøgning for dette datasæt, giver en betydelig øget udførelsestid i forhold til både den kombineret løsning og seedand-extend alene. Ved kun at bruge Pash til den indledene ankersøgning fås højere sensitivitet og lavere udførelsestid end seed-and-extend alene. Eftersom Pash har vist nogle svagheder ved brug til den eksterne ankersøgning på repetitive sekvenser, har vi valgt at nøjes med at bruge den til den indledende ankersøgning i sammenligningen med andre programmer. Erfaringer fra Pash Pash har vist sig at være en god løsning til den indledende ankersøgning. Den har mulighed for at tilpasse sig hukommelsesforbruget ved opdeling i flere diagonaler. Pash kan også bruges til ekstern ankersøgning, såfremt det er muligt at lave en bedre filtrering af resultater, så den kan bruges på repetitive sekvenser, uden at udførelsestiden stiger kraftigt. I kapitel 6 har vi testet hvordan Pash til den indledende ankersøgning klarer sig, sammenlignet med andre algoritmer, på større datasæt. 5.2 MUM s for delmængder af sekvenser Med inspiration i nogle af de ekstra funktioner som Progressive Mauve fra afsnit har, kigger vi i dette afsnit nærmere på betydningen for en alignment når MUM s for delmængder af sekvenser medtages. Vi har valgt at begrænse os, som tidligere

75 70 KAPITEL 5. UDVIKLING AF FINAL nævnt, til at se på konsekvensen for kvaliteten, frem for også at bekymre os om tid og hukommelse. Af denne grund betragtes følgende afsnit og tilhørende implementering som en eksperimentel udgave, som udforsker potentialet i denne ændring. Overordnet er fremgangsmåden anderledes når der kun findes MUM s i en delmængde af sekvenserne. Progressive Mauve finder MUM s mellem alle sekvenser parvist og efterfølgende større delmængder ad gangen. Vi har valgt at finde delmængde MUM s mens alle sekvenser betragtes samtidigt. Dette er valgt, da det krævede færre ændringer og påvirker ikke kvaliteten. Selvom det at tage højde for delmængde MUM s kræver forholdsvis gennemgående ændringer, så er de fleste trivielle at foretage. Derfor vil vi kun beskrive to algoritmiske forskelle og derefter kigge på hvilken indflydelse, vores samlede ændringer har på kvaliteten af en alignment Identifikation af MUM s For at inkludere MUM s der kun findes i en delmængde af sekvenser, er det nødvendigt at ændre på metoden hvormed disse findes. Tidligere for seed-and-extend, ved gennemløb af sorterede k-mers, kunne man tillade sig at konkludere, at en k-mer ikke var en del af en MUM, så snart der var to k-mers der var forskellige. Nu er det nødvendigt at sammenligne alle delmængder af k-mers. Dette løser vi ved først at oprette en heap som indeholder første k-mer fra hver sekvens. Efterfølgende itererer vi over følgende trin, for at finde MUM s undervejs, så længe det er muligt: Fjern den leksikografisk mindste k-mer fra heap en. Sammenlign denne k-mer med den som blev fjernet ved forrige iteration, såfremt de ikke er fra samme sekvens. Hvis de er ens, huskes begge. Hvis de ikke er ens, kigges der på om der tidligere var fundet nogle k- mers som var ens og dermed muligvis udgør en MUM. Indsæt næste k-mer fra samme liste den tidligere blev fjernet fra. Et andet problem, der efterfølgende skal håndteres, er det at tjekke om en given k-mer allerede er indeholdt i en eksisterende. Vores tidligere løsning med at benytte et boolean array fungerer ikke, da MUM s ikke nødvendigvis har en k-mer i første sekvens. Endvidere ville et array for hver sekvens stadig kunne give anledning til at MUM s mellem delmængder, med større multiplicitet, kunne blive kasseret. Altså kan en MUM i tre sekvenser blive kasseret til fordel for en anden MUM, der kun findes i to af sekvenserne. Derfor har vi valgt at tage udgangspunkt i Mauves løsning med en hashtabel og ændret den til vores formål.

76 5.2. MUM S FOR DELMÆNGDER AF SEKVENSER 71 Måden hvorpå vi holder styr på eksisterende MUM s, er ved at have en hashtabel for hver sekvens, hvor Mauve kun samlet har én hashtabel. Hver MUM bliver tilføjet til hashtabellen for den første sekvens den spænder over. Denne løsning er ikke perfekt, idet den finder for mange MUM s, men den sørger for, ikke at kassere nogle fejlagtigt. Disse ekstra dubletter spænder over forskellige sekvenser og kan nemt efterfølgende filtreres fra. Dette kan stadig fint opfylde målsætningen med at teste indflydelse på kvaliteten af den endelige alignment, selvom det kan have en negativ indflydelse på udførelsestiden. Eksempelvis hvis tre sekvenser betragtes, kan en MUM med multiplicitet tre også give anledning til at tre MUM s med multiplicitet to findes. Måden hvorpå vi efterfølgende løser overlaps mellem MUM s, er ved at prioritere MUM s med højere multiplicitet, således at kvaliteten ikke bliver negativt påvirket Gruppering af MUM s i kolinære blokke Et andet trin som er markant forskelligt, er hvordan MUM s grupperes til LCB er. Her udvider vi definitionen af LCB er til, at ud over at skulle bestå af kolinære MUM s, endvidere skal have samme multiplicitet. Dette medfører både fordele og ulemper: Fordelen er at det giver simple LCB er, der er lettere at håndtere og aligne efterfølgende. Såfremt MUM s med forskellig multiplcitet var tilladt i samme LCB, ville det give anledning til tvetydige tilfælde omkring hvordan gaps skulle indsættes i de øvrige sekvenser, som ikke er en del af en given delmængde MUM. Konsekvensen for at kræve samme multiplicitet for alle MUM s i en LCB er, at det kan give anledning til flere LCB er. Dette kommer af at hvad der uden delmængde MUM s udgjorde en LCB, nu ikke kan grupperes i samme omfang og derfor udgør flere LCB er. Dette kan føre til en meget opdelt alignment. Vi har prøvet at kompensere for dette ved at indføre et ekstra krav for størrelsen af delmængde MUM s, for at de rent faktisk bidrager med noget, frem for blot at opsplitte ellers forholdsvis regulære LCB er Vi udvider greedy breakpoint elimination algoritmen fra afsnit til at håndtere delmængde MUM s, ved ikke først at foretage en nummerering af MUM s ordning jævnfør første sekvens. I stedet nummereres MUM s som de observeres efter sortering efter hver sekvens, såfremt de ikke allerede er blevet tildelt et nummer. Et eksempel på en sådan nummerering fremgår af figur 5.4. Dette bevirker at nummereringen automatisk sørger for at MUM s samles korrekt i LCB er, og multipliciteten behøves således ikke at blive overvejet Evaluering af delmængde MUM s Næste skridt er at evaluere om hvorvidt disse delmængde MUM s giver anledning til en bedre alignment. Da der er tale om en eksperimentel implementering, har vi valgt at sætte en minimumsstørrelsen på nukleotider, for at en delmængde

77 72 KAPITEL 5. UDVIKLING AF FINAL I J K L I M J L I J K M L Figur 5.4: Eksempel på nummerering af delmængde MUM s. Det ses at nr. 5 findes til sidst da den først observeres ved gennemløb af nummer to sekvens. Udførelsestid for 3bac fordelt over faser for delmængde MUM s og Final YTTXZQPXZT[\TPX STRUVPWXT NOPQR ]^TTX_ `^TQabcOP\ TROUOPQ\OcP dae\t^p QPaT^efWPOPW gp\t^p QPaT^efWPOPW ]QbbTX QROWPUTP\ nop qrost h i j k l mh mi mj Figur 5.5: Allerede ved tre bakteriegenomer ses en kraftig forøgelse i udførelsestiden i forhold til Mauve, specielt i seed-and-extend fasen. MUM medtages. Denne størrelse var nødvendig, da der ellers forekom en kraftig opsplitning af LCB er sammenlignet med uden delmængde MUM s. Den konkrete minimumsstørrelsen var mindre vigtig og vil kunne i en endelige version baseres på sekvenslængden som Mauve allerede gør med andre konstanter. De viste dog et udmærkede resultat for de undersøgte datasæt. Dette viser også at det er nødvendigt i en endelig udgave at sortere i mængden af resultater. Vi har valgt at evaluere på to forskellige datasæt. I det første er alle sekvenser forholdsvis identiske, hvor de i det efter efterfølgende datasæt kun er parvist identiske. Datasæt med flere sekvenser ville have været ønskværdigt, men da denne eksperimentelle version har en mindre heldig udførelsestid, har vi undladt dette. Som det ses af figur 5.5 har delmængde MUM s en stor udførelsestid relativt til Mauve. Det kan af figuren bemærkes, at intern ankersøgning for delmængde MUM s er udeladt. Dette skyldes praktiske årsager og er mindre væsentligt da det ikke får nogen indflydelse på kvaliteten af betydning. Tests af kvalitet fremgår af tabel 5.2 og tabel 5.3. Det ses at inkluderingen af

78 5.3. OPTIMERING AF ENDELIG UDGAVE 73 Kvalitet for fire nært beslægtede bakterier Final Delmængde MUM s Mauve 1.2 Sensitivity 0,8895 0,9029 0,8837 PPV 0,9997 0,9986 0,9997 Tabel 5.2: Test af kvalitet for datasæt med fire bakterier (4bac1) der alle er af samme art. Kvalitet for fire parvist nært beslægtede bakterier Final Delmængde MUM s Mauve 1.2 Sensitivity 0,9243 0,9524 0,9013 PPV 0,9644 0,9670 0,9746 Tabel 5.3: Test af kvalitet for datasæt med fire bakterier (4bac2) der er parvis af samme art. delmængde MUM s giver anledning til større sensitivitet. Der ses især en markant forbedring af sensitiviteten, når kun en delmængde af sekvenserne er nært beslægtet, hvilket var at forvente. Med hensyn til kvaliteten af den endelige alignment så ses det at den forbedres når delmængde MUM s medtages idet at PPV stort set er uændret. Samlet ser vi en forbedring når delmængde MUM s betragtes og denne kan kun forventes at blive større som flere sekvenser medtages. Der er stadig visse algoritmiske problemer der mangler at blive løst før vores løsning er anvendelig rent tidsmæssigt. Vores målsætning med at udforske potentialet for forbedret kvalitet er dog opnået. 5.3 Optimering af endelig udgave Vi har forsøgt at optimere seks aspekter af vores alignment implementering ud fra det princip, at kvaliteten skal forsøges bevaret under forbedringer af udførelsestiden og hukommelsesforbruget. De konkrete optimeringer er valgt ud fra enten ideer fra andre algoritmer eller kritiske dele af implementeringen observeret ved profilering. Første optimering omhandler sammenfletningen af flere lister af k-mers i seedand-extend fasen og er baseret på en tidligere omtalt ide i afsnit 4.2.1, nemlig en heap. Den anden optimering omhandler alternative metoder til at detektere når en k-mer er en del af en allerede eksisterende MUM. Tredje optimering omhandler hvordan genberegning af LCB er kan undgås for hver iteration af Greedy Breakpoint Elimination. I fjerde afsnit optimeres søgning efter ankre internt i LCB er ved at huske hvilke LCB er der allerede er blevet søgt i. Det femte afsnit beskriver hvor-

79 74 KAPITEL 5. UDVIKLING AF FINAL yz{ z}~ u v w x ~ ~ ƒƒz} z } }ˆ w x u v Š z~ ~ ƒƒz} z } }ˆ Figur 5.6: Nederst på illustrationen ses fire lister af k-mers. Disse k-mers forekommer alle i den samme sekvens som ses øverst. De fire nummererede blokke viser hvilke k-mers i sekvensen der kunne indgå i en konkret fletning. Fletning kan enten gøres parvist eller eller samlet. dan vi har forsøgt at optimere kvaliteten af vores alignment ved i større omfang at acceptere LCB er med længere afstande mellem ankre. Til sidst har vi kigget på konsekvensen af at opsplitte raffineringsfasen, hvor der søges efter eksterne og interne ankre. Hvert afsnit for en optimering afsluttes med en selvstændig evaluering af hvilken effekt der opnåes. Fælles for de fleste af disse tests er at resultaterne der præsenteres er foretaget på det samme datasæt bestående af tre bakterier (3bac). Hver optimering kunne analyseres nærmere for forskellige datasæt for at undersøge skaleringen med sekvensstørrelse og antal, men i stedet evalueres det samlede resultat i kapitel 6. Grunden til valget af dette datasæt er, at vi ønsker at vurdere hvor godt vi klare os i praksis, hvilket også kræver et rigtigt datasæt. Ud over dette ene bakterielle datasæt, har vi også gentaget hver test på et datasæt fra vores sekvenssimulator (3bsim5), for at se om samme tendens blev observeret. Fokus for evalueringen af hver optimering er om der er tale om en forskel der kan retfærdiggøre bevaring af ændringen, frem for præcis hvor stor en forbedring der er tale om Bedre sammenfletning af blokke med k-mers Som allerede observeret i afsnit 4.2.1, så når der haves flere blokke af k-mers som skal flettes sammen, kan mere end to flettes samtidigt ved at opretholde en heap over en kandidat fra hver blok. En illustration af hvordan dette gøres fremgår af figur 5.6. Dette har vi valgt at implementere i et forsøg på at forbedre udførelsestiden. Antagelsen er at selvom den asymptotiske udførelsestid ikke bliver forbedret, så læser og skriver denne løsning kun hver k-mer én gang til et IoArray. For at vurdere konsekvensen af ovenstående ændring har vi valgt at simulere hvad der sker ved større datasæt. Nemlig at der sker en opsplitning i et større antal blokke, hvilket er gjort ved at ændre blokstørrelsen til 10 5 frem for normalt Resultatet af den nye metode for sammenfletning, fremgår af figur 5.7. Det ses me-

80 5.3. OPTIMERING AF ENDELIG UDGAVE 75 ª«ª«ª œ žÿ Œ Ž Ž ± ª²³± µ ¹ º» ± ±»¼½ ½ ¾ ± ±»¼½ ½ š ŒŒ Ž Ž µµ ª ½ ¹ Ž Ž ŒŽ Ž ŽŽ Ž ŒŽ Ž ŽŽ Ž ŒŽ Ž Figur 5.7: Tidsforbruget for de forskellige faser for både parvis og samlet fletning af blokke over k-mers. get tydeligt at både sammenfletningen for seed-and-extend, samt ekstern ankersøgning, bliver kraftigt forbedret når der haves mange blokke. Var blokstørrelsen uændret så ville seed-and-extend ikke være forskellig, mens ekstern ankersøgning stadig ville have set en lige så stor forbedring. Ved en gentagelse af dette eksperiment på datasættet med tre genererede sekvenser blev en meget lignende tendens observeret. Vi konkluderer derfor at denne optimering, som forventet, giver en hastighedsforbedring Bedre detektion af eksisterende MUM s Både Prototype- og Draftudgaven anvender et array af booleans til at holde styr på hvilke områder af sekvenserne som allerede er inkluderet i en eksisterende MUM. Problemet med et array af booleans i Java er at der reelt bliver brugt en byte frem for en enkelt bit for hver boolean. Dette har vi forsøgt at forbedre ved at lave et komprimeret array, hvor der netop bliver brugt en bit. Dette gøres ved at have et array over integers og så gemme 32 booleans heri. Der benyttes elementære regneoperationer, så som bit shift, for at pakke de enkelte booleans i disse værdier af integers. At dette giver en faktor 8 reduktion af hukommelsesforbrug er simpelt at se. Effekten af denne reduktion forventes at blive endnu større i fasen hvor vi søger efter interne ankre, da der for hver parallel søgning kræves et array. Hvad angår udførelsestiden så vil vi gerne stadig have tider der minder om dem vi fik for et boolean array. Dette har vi forsøgt at opnå ved at udnytte at vi netop ofte ønsker at tjekke om et større interval er sat til sand og er grunden til at vi ikke har brugt det indbygget BitSet i Java. Netop denne type operationer kan i visse tilfælde reduceres til at tjekke om alle bits for én integer er sande, hvilket i Javas to-komplements repræsentation svarer til at se om integeren har værdien 1. Som det fremgår af afsnit benytter Mauve en hashtabel og hvad de kalder generaliseret offset. Fordelen ved denne metode er at hukommelsesforbruget ska-

81 76 KAPITEL 5. UDVIKLING AF FINAL Hukommelsesforbrug over tid final-normalt-array final-hashtabel final-komprimeret-array Hukommelse [mb] Tid [s] Figur 5.8: Sammenligning af hukommelsesforbrug for kompakt boolean array, hashtabel og normalt boolean array til detektion af eksisterende MUM s som indeholder en given k-mer. lerer med antal MUM s frem for længden af sekvenserne og af denne grund har vi prøvet at implementere denne metode for at se hvordan den også klare sig. Kigges der på figur 5.8 ses en sammenligning mellem det oprindelige boolean array, den komprimerede udgave samt udgaven med en hashtabel og generaliseret offset. Testen er baseret på et datasæt med to sekvenser af en længde omkring 33 MB fra kromosom X fra menneske og mus (2mam33). Kigges der på tidsintervallet på figuren mellem 300 og 700 sekunder ses forskellen. Det forventes at forskellen er omkring 30 MB mellem et normalt array og det komprimerede og figuren viser at der også er en forskel. Dette er ikke en stor forskel, men når der huskes på at den resterende hukommelse bliver brugt af IoArray s som kan lagres på disken, så for større sekvenser kan forskellen blive væsentlig. Hashtabellen bruger overraskende mere hukommelse. Der skal dog knyttes en bemærkning her til da hashtabellen ikke er implementeret så kompakt som det er muligt. Der er blot brugt Javas hashtabel samt et søgetræ for flere indgange der hasher til samme indgang. For den indledende søgning efter MUM s virker det ikke optimalt for de undersøgte sekvenser at benytte en hashtabel. Disse alternativer forventes at kunne bidrage yderligere til minimering af hukommelsesforbruget når der foretages parallelisering af de senere iterationer, hvor LCB er forbedres, da der netop for hver tråd kræves et array eller en hashtabel.

82 5.3. OPTIMERING AF ENDELIG UDGAVE 77 Kigges der igen på figur 5.8 ses at for de perioder efter 900 sekunder hvor hukommelsesforbruget er lavest, hvilket er under søgning efter ankre internt i LCB er, der kommer den ekstra hukommelse som det traditionelle array kræver til udtryk. Ydermere ses det, at da der netop findes et langt mindre antal MUM s, at hastabellen har det laveste hukommelsesforbrug. Selvom figur 5.8 har til formål at vise udviklingen i hukommelsesforbrug, så giver den også en ide om at ikke alle disse metoder er lige hurtige. Der kan ikke regnes med de præcise tider fra grafen da visse faser og metoder er mere påvirket af hukommelsesmålingen og derfor har vi lavet en selvstændig måling af tidsforbruget: Normalt Komprimeret Kombineret Fase [s] Hashtabel array array løsning Seed-and-extend 515,42 513,04 548,24 509,10 Ekstern ankersøgning 315,19 317,47 294,05 308,56 Intern ankersøgning 808,53 303,05 248,95 256,79 Total tid 1657, , , ,25 Af ovenstående tabel ses det at det komprimerede array klare sig bedst i seedand-extend, hvor hashtabellen har en fordel under specielt søgning efter interne ankre i LCB er. Dette giver fint mening fordi at der for hashtabellen ikke skal nulstilles et array for hver eneste interval, da disse søgninger er uafhængige af hinanden. Derfor, inspireret af ovenstående forsøg, har vi prøvet kombinere det komprimerede array og hashtabellen så førstnævnte bruges til først global søgning efter MUM s og derefter bruges hashtabellen. Tidsforbruget af denne kombination er som vi kunne forvente, hvilket også fremgår af samme tabel, nemlig at kombinationen for denne test er hurtigst. Med hensyn til hukommelsesforbruget af denne kombinerede løsning så var der intet uventet af denne graf, dvs. kombinationen af de to metoder ingen utilsigtede konsekvenser havde og den fremgår derfor kun af bilag B.1.2. Vi vælger at benytte den kombinerede løsning da den klare sig bedst både hvad angår hukommelsesforbrug og udførelsestid. Den forventes også at skalere endnu bedre end de øvrige løsninger. Vi har gentaget ovenstående på datasættet med tre genererede sekvenser og der observerede vi samme tendens. Ud over tests af tid og hukommelse, har vi også kigget på om brugen af det generaliseret offset og en hashtabel kan give anledning til en forskel i kvaliteten. Vi har tidligere i afsnit beskrevet hvordan der muligvis kan forekomme en forskel. For datasættet bestående af tre bakterier oplevede vi ingen forskel. Vi har dog oplevet mindre forbedringer i kvaliteten ved andre kombinationer af datasæt (4bac1, 4bac2 og 4bac3), men af mindre betydning. Vi anser både optimeringen med et komprimeret array og en hashtabel som værende interessante ændringer. Den præcise konsekvens afhænger af datasættet.

83 78 KAPITEL 5. UDVIKLING AF FINAL Hvad angår hukommelsesforbruget og udførelsestiden er kombinationen af disse to metoder den bedste. Med hensyn til kvalitet så er kombinationen også generelt en god løsning og derfor også det endelige valg Hurtigere bestemmelse af LCB er En mangel i Draftudgaven var at hver iteration som frasorterede LCB er med lav score startede forfra med at finde LCB er, hvor Prototypen rent faktisk sammenflettede de eksisterende LCB er. Vi har valgt at lave den samme optimering i denne version. Denne optimering forventes at give en reduktion i udførelsestiden af væsentlig karakter set isoleret for denne fase, mens globalt vil det være begrænset hvad betydning den får. Vi anså den alligevel som relevant at lave, da der er tale om en optimering, som ikke kræver et kompromis med hensyn til andre parametre som hukommelse eller kvalitet. Fremgangsmåden er stadig den samme som fremgik af afsnit 3.2, med den forskel, at der er flere tilfælde for breakpoints som skal håndteres grundet at reversekomplementet er medtaget. Som tidligere observeret kan denne sammenfletning af LCB er laves ved at anvende fremgangsmåden for bestemmelse af LCB er ud fra MUM s. Der skal kort sagt tages højde for om to LCB er, som er mulige kandidater til at blive flettet sammen, har samme orientering og ikke har andre LCB er mellem sig i en eller flere sekvenser. Tests viser at konsekvensen af at sammenflette LCB er er at kvaliteten og det maksimale hukommelsesforbruget er uændret, mens udførelsestiden ser ud som følgende: Tider [s] Merge af Genberegning LCB er af LCB er Tid for at finde LCB er 1,59 11,13 Total tid 121,04 129,50 Ovenstående viser en forbedring på 85,71% for at finde LCB er, hvilket totalt giver en forbedring på 6,53%. En forbedring af denne størrelse var forventlig da der netop kun kigges på hver LCB frem for hver MUM, hvilket i værste tilfælde vil give samme udførelsestid. Ved en gentagelse af ovenstående test på de tre genererede sekvenser var situationen angående udførelsestid en anden. For dette datasæt blev der fundet mange LCB er og foretaget flere iterationer. Dette gav anledning til at optimeringen for sammenfletning af LCB er halverede den samlede udførelsestid. Derfor anser vi ovenstående optimering som en der i nogle tilfælde kan være yderst fordelagtig og generelt giver en fornuftig forbedring.

84 5.3. OPTIMERING AF ENDELIG UDGAVE Optimering af intern søgning efter MUM s i LCB er I fasen hvor der foretages søgning efter ekstra MUM s internt i LCB er iterativt, ændre nogle LCB er sig. Dette betyder også at der vil være LCB er som ikke vil ændre sig mellem to iterationer og netop disse er ikke nødvendige at undersøge for interne MUM s igen, da omstændighederne ikke har ændret sig. Vi husker derfor hvilke LCB er vi allerede har søgt i for at kunne udelade disse. Måden hvorpå disse huskes og ændringer detekteres, er ved at udregne et id som ændre sig såfremt de interne MUM s ændre sig. Id et udregnes ved at sumerere over start- og slutpositioner for alle interne MUM s. Dette kan godt give anledning til visse LCB er fejlagtigt identificeres som allerede værende gennemsøgt. Dette er selvfølgelig et problem som skal minimeres i det omfang det kan lade sig gøre, men det er vigtigt at bemærke at de kollisioner der måtte opstå ikke giver anledning til fejl i resultatet, blot et mindre optimeret resultat. Det at interne MUM s muligvis ikke findes kan have flere konsekvenser. Den mest harmløse er at Muscle blot sørger for at aligne det pågældende område. Dette kan betyde en forøgelse af udførelsestiden samt en risiko for at Muscle kommer til at lave en alignment der er anderledes. En mindre heldig konsekvens kan være at afstanden mellem to MUM s i en LCB er så stor at det giver anledning til en opsplitning af LCB en. Det endelige resultat vil derfor være mindre læseligt da der haves flere små blokke. For at se hvilke praktiske konsekvenser det har at visse LCB er ikke gennemsøges for interne MUM s for hver iteration, udførte vi en række tests for at se på om kvaliteten bliver påvirket, samt hvilken indflydelse det har på udførelsestiden. Først bemærkede vi at kvaliteten af den endelige alignment var uændret. Dette fortæller os at selvom vi forventede potentielle forringelser så er det begrænset eller slet ikke eksisterende i praksis. Indflydelsen på udførelsestiden for denne optimering har vi også undersøgt og følgende tabel viser resultatet: Tider [s] Ingen genberegning Genberegning Tid for interne ankre 28,52 41,1 Total tid 121,04 137,48 Af tabellen ses det at der opnås en forholdsvis stor hastighedsforbedring. For selve det at finde interne ankre opnås en forbedring på 30,61%. Den totale udførelsestid forbedres med 11,96%. Meget lignende forbedringer observeres ligeledes på det generede datasæt med tre sekvenser. Derfor anser vi denne optimering som værende yderst fordelagtig.

85 80 KAPITEL 5. UDVIKLING AF FINAL ÊËÁ ÀÁÂ ÄÅÄÆ ÄÅÄÇ ËÌ ÀÁÃ ÄÅÄÆ ÄÅÄÇ ÍÁ ÀÁÈ ÄÅÄÆ ÄÅÄÇ ÎÏÌÁ ÀÁÉ ÄÅÄÆ ÄÅÄÇ Figur 5.9: Illustration af forskellige afstande mellem ankre Simpel alignment af store afstande mellem ankre Visse LCB er har store afstande mellem ankre som vi ofte lader Muscle aligne. Som beskrevet i afsnit 4.5 var det sommetider nødvendigt at splitte LCB er i to såfremt afstanden var for stor for Muscle. Dette har vi forsøgt at kompensere for ved at udvide mængden af alignments som vi kan håndtere uden Muscle og derfor kan nøjes med færre opsplitninger. Vores nye strategi nøjes med at opsplitte en given LCB såfremt afstanden mellem to ankre er for stor i samtlige sekvenser. Tidligere foregik opsplitningen allerede hvis bare én sekvens havde en for stor afstand mellem to ankre. Ideen med denne ændring er at vi nu håndtere disse store afstande anderledes. Vores nye strategi introducerer således to nye tilfælde hvor vi selvstændigt foretager en alignment. Hvis ikke afstanden i alle sekvenser er for stor til at kunne håndteres af Muscle foretager vi ingenting for den delmængde af afstande der er for stor. I stedet nøjes vi med at tilføje gaps i slutningen af de øvrige alignments. For at kompensere for, at vores nye strategi medtager sådanne forholdsvis store afstande, så har vi yderligere valgt, at det ikke helt giver mening at aligne afstande i de sekvenser mellem MUM s der er forholdsvis små. Derfor aligner vi ikke hvor afstanden er under 10% af den maksimale afstand mellem to givne MUM s. Et eksempel hvor ovenstående to ændringer træder i kraft fremgår af figur 5.9. I eksemplet kunne grænsen for brug af Muscle være 10k nukleotider. Dette vil betyde at afstanden i Sek 1 er for stor til at håndtere og efterlades derfor urørt. I Sek 3 og Sek 4 er afstanden passende i størrelse og der alignes derfor med Muscle. Efterfølgende tilpasses længden med den største afstand som er 12k ved at tilføje gaps. For Sek 2 er afstanden så lille at det ikke rigtigt giver mening at sammenligne den med de øvrige og den efterlades urørt og tilføjes et antal gaps så den passer med 12k også. Var det tilfældet at der var flere afstande over den maksimale grænse så tilpasses de

86 5.3. OPTIMERING AF ENDELIG UDGAVE 81 Final 10k Final 20k Final 10k Final 20k aggressiv aggressiv Mauve 1.2 Sensitivity 0,9207 0,9339 0,9425 0,9425 0,9300 PPV 0,9989 0,9980 0,9980 0,9980 0,9983 Tabel 5.4: Test af kvalitet for datasæt med tre bakterier. mindste af disse også til den maksimale længde. Ovenstående ændring forventes at resultere i flere store LCB er med flere områder der er mindre godt alignet internt. Om dette er ønskværdigt kan variere alt efter om målet er at få overblik over kolinære områder mellem flere sekvenser for nærmere analyse, eller om man gerne vil have en detaljeret sammenligning. Det at tillade større afstand ændre ikke på at det stadig er kolinære blokke, men en stor afstand mellem områder der matcher godt, kan også betyde at de ikke er relateret og derfor måske ikke bør omfattes af den samme LCB. For at se præcis hvilken konsekvens ovenstående alternative fremgangsmåde kan have, har vi lavet en række tests af kvaliteten for forskellige alignments. Vi har evalueret både hvilken forskel det gjorde hvis vi valgte at variere den maksimale afstand som Muscle skulle håndtere og betydningen af ovenstående mere aggressive metode. Vi har medtaget flere datasæt end tidligere da markante forskelle viste sig. Tabel 5.4 for datasættet 3bac viser ganske som forventet at muligheden for at håndtere større LCB er også giver en forøgelse af størrelsen på LCB er og dermed inkluderes mere af sekvenserne i en alignment. Dette er gældende både ved første skridt, hvor størrelsen af gaps som håndteres forøges fra 10k til 20k, og efterfølgende, hvor den aggressive metode benyttes. Det ses også at PPV ikke falder noget af betydning og der er tale om en forbedring af kvaliteten. Den egentlige ide til at have muligheden for ovenstående ændringer skyldes yderligere kontrol med kvaliteten på forskellige sammensatte datasæt. Nogle af disse viste markante fald i kvaliteten af alignment en og inkluderes derfor her. Der er tale om tre datasæt hver bestående af fire bakterier. Kigges der samlet på tabel 5.5, 5.6 og 5.7, så er der et tydeligt faldt i størrelsen af LCB er da sensitivity for versionen med afstande op til 10k er markant lavere. Både det at afstande på 20k og mere aggressiv alignment medtages, medfører store stigninger i hvor meget af Progressive Mauves LCB er som findes. For disse datasæt skal det dog bemærkes at PPV falder som der medtages større afstande. Dette er klart mindre heldigt, men heller ikke overraskende, da der ikke filtreres i hvilke tidligere LCB er der nu udgør én. Hvad der ikke direkte fremgår af ovenstående tabeller er ydermere at det reelle antal falsk-positive stiger forholdsvis kraftigt. Så med skiftet til en mere aggressiv strategi findes en alignment hvor LCB er mere er områder som er blot kolinære frem for også i større omfang at være homologe.

87 82 KAPITEL 5. UDVIKLING AF FINAL Final 10k Final 20k Final 10k Final 20k aggressive aggressive Mauve 1.2 Sensitivity 0,8267 0,8535 0,8868 0,8895 0,8837 PPV 0,9998 0,9997 0,9997 0,9997 0,9997 Tabel 5.5: Test af kvalitet for datasæt med fire bakterier der alle er af samme art (4bac1). Final 10k Final 20k Final 10k Final 20k aggressive aggressive Mauve 1.2 Sensitivity 0,7970 0,8563 0,9157 0,9243 0,9013 PPV 0,9958 0,9951 0,9660 0,9644 0,9746 Tabel 5.6: Test af kvalitet for datasæt med fire bakterier der er parvis af samme art (4bac2). Final 10k Final 20k Final 10k Final 20k aggressive aggressive Mauve 1.2 Sensitivity 0,7739 0,8204 0,8870 0,8870 0,8763 PPV 0,9886 0,9982 0,9864 0,9864 0,9890 Tabel 5.7: Test af kvalitet for datasæt med fire bakterier hvor tre er af forskellig art (4bac3). Overordnet vurderer vi at den mere aggressive håndtering af afstande mellem LCB er giver en væsentlig forbedring hvad angår overblik over områder som er kolinære. Dette sker på bekostning af om hvorvidt disse områder også er homologe. De største forskelle ses ved sekvenser som afviger fra hinanden. Derfor, alt efter formålet med den pågældende alignment, kan begge metoder være relevante og vi bevarer muligheden for at skifte mellem den oprindelige metode samt den mere aggressive. Ligeledes kan afstanden som Muscle håndterer også varieres. En sidste kommentar bør knyttes til hvilken indflydelse disse to parametre har på udførelsestiden. Det at ændre afstanden for gaps fra 10k til 20k har på de tre datasæt med fire bakterier betydet en forøgelse på gennemsnitlig 25% af udførelsestiden for kald af Muscle. Hvis der derimod ses på konsekvensen af at skifte til den aggressive strategi, er den at udførelsestiden gennemsnitlig er uændret. Der er altså væsentlige forøgelser i udførelsestiden når Muscle anvendes til støre afstande da det netop er disse som kræver ekstra tid for traditionelle alignment metoder som diskuteret i afsnit 2.4. Denne forøgelse i udførelsestid kan derfor også spille ind på hvilke parametre der bør vælges såfremt udførelsestiden er væsentlig Opsplitning af iterationsfase I Draft forsøgtes kvaliteten af LCB er at forbedres ved iterativt at fortage ekstern og intern ankersøgning, hvilket blev beskrevet i afsnit 4.4. Det at en af disse to metoder føre til nye MUM s betyder ikke nødvendigvis at den anden også gør og af denne grund kiggede vi lidt nærmere på hvad der sker hvis de opsplittes.

88 5.4. OPSUMMERING AF FINAL 83 Først itererer vi så længe det er muligt at foretage ekstern ankersøgning for at få fastlagt grænserne for alle LCB er. Når dette ikke længere giver nogen forbedring, itererer vi så længe intern ankersøgning finder yderligere MUM s som kan stabilisere og hjælpe gapped alignment. Denne opsplitning og rækkefølge af de to trin er mulig, idet intern ankersøgning ikke ændre på start og slut for den pågældende LCB og kan derfor ikke give anledning at ekstern ankersøgning ændre opførsel. Konsekvensen af opsplitningen er i værste tilfælde at LCB er genberegnes et yderligere antal gange, men dette er allerede kraftigt optimeret og derfor ikke et stort problem. Følgende tabel viser fire eksempler på konsekvensen af denne opslitning: Samlet Opsplittet Forbedring Datasæt ankersøgning [s] ankersøgning [s] [procent] 3bac 51,35 58,42 13,43% 4bac1 62,47 45,69 26,86% 2mam14 217,11 135,17 37,74% 2mam33 958,40 584,89 38,97% Det ses af ovenstående tabel at det ikke er konsekvent hvor stor en forbedring en opsplitning af iterationsfasen giver. Den negative forbedring for tre bakterier skyldes at der ikke foretages færre kald af ekstern og intern ankersøgning og i stedet skal LCB er genberegnes oftere. Såfremt dette skulle være tilfældet på et større datasæt ville den procentuelle forskel være betydelig lavere da bestemmelse af LCB er er et af de trin som skalerer godt. Derfor vurderer vi at opsplitning af iterationsfasen ofte giver en stor hastighedsforøgelse og i værste tilfælde giver en ubetydelig forøgelse af udførelsestiden. 5.4 Opsummering af Final Som nævnt først i dette kapitel, er evalueringen af Final udskudt til kapitel 6, da der ønskes testet flere aspekter og sammenligner med flere programmer frem for kun en sammenligning med Draft. Dog opsummerer vi kort hvad der er blevet kigget på i Final da det giver en ide om fokus for evalueringen. Brugen af Pash, til den indledende ankersøgning, var ganske succesfuld. Pash gør det muligt at bruge mindre hukommelse, parallelisere til flere kerner samt at opnå højere sensitivitet for nogle datasæt. Den nuværende udgave har dog ikke været brugbar til ekstern ankersøgning, da den for nogle datasæt kan give anledning til en stor stigning i den samlede udførelsestid. Vi har undersøgt hvilken betydning det har hvis MUM s mellem delmængder af sekvenser betragtes. Her var resultatet at det fører til en fornuftig forbedring af kvaliteten for den pågældende alignment. Udfaldet varierer dog med type af data og antallet af sekvenser. Vi har vist at det godt kan lade sig gøre at finde disse MUM s

89 84 KAPITEL 5. UDVIKLING AF FINAL uden at kigge parvist på alle sekvenser dog uden med sikkerhed at vide om det kan gøres tidsmæssigt effektivt. For at sikre at Final har en fornuftig udførelsestid, har vi kigget på en række optimeringer. Specielt har der været fokus på skalering ved større sekvenser. Der er også blevet kigget på en mere aggressiv strategi for alignment er LCB er, hvilket også kan give en højere kvalitet. Hver enkelt optimering har vist potentiale på enkelte datasæt, men mere dybdegående tests af det endelige resultat fremgår som sagt af næste kapitel.

90 K A P I T E L 6 RESULTATER Dette kapitel indeholder først en gennemgang af hvordan vi har evalueret vores tre implementeringer: Prototype, Draft og Final. Vi har for hver evalueret korrekthed, kvalitet, hukommelsesforbrug og udførelsestid. Denne gennemgang indeholder desuden en detaljeret beskrivelse af baggrunden og fremgangsmåden for hvert evalueringsaspekt. Efter gennemgang af dette kommer resultater i afsnit 6.8 hvor vi sammenligner vores Final udgave med alternative programmer til alignment af hele genomer. 6.1 Korrekthed af implementering og alignment Evaluering af korrektheden er ikke trivielt for et program der består af mange faser og hvor der ikke findes nogen endegyldig rigtig reference. Selvom der er en bagvedliggende evolutionær historie for hver sekvens, så kan visse informationer sagtens være gået tabt og derfor ikke mulige at tage højde for. Ligeledes eksisterer der ikke nogle fyldestgørende modeller for evolution over længere tid. Vores mål er derfor ikke at vise fuld korrekthed, men derimod at vise at hver fase af algoritmen opfører sig som forventet og at der ikke er nogle inkonsistente data i mellemliggende og endelige resultater. Samtidigt ønskes at resultatet ikke viser en uforklarlig stor afvigelse fra et reference datasæt. Denne overensstemmelse med en reference betegner vi som kvaliteten og kigges nærmere på i afsnit 6.2. Et værktøj vi har benyttet gennem hele projektet til at sikre den ønskede opførsel er unit tests. For hver af de væsentlige aspekter af hver fase, har vi konstrueret en række tests som forsøger at dække både grundlæggende tilfælde samt grænsetil- 85

91 86 KAPITEL 6. RESULTATER fælde. Unit tests er en meget omfattende metode til validering af forventet opførsel, men grundet vores iterative arbejdsproces har den været yderst brugbar. For hver iteration af udviklingen har vi nemt kunne teste at tidligere opførsel var bibeholdt. Såfremt det ikke var tilfældet, havde vi endvidere simple tilfælde at tage udgangspunkt i, for at lokalisere og rette fejlen. Unit tests er ikke nogen garanti for et korrekt resultat, da forkerte antagelser eller manglende overvejelser også kan komme til udtryk i tests, men kombineret med andre metoder, er de et godt fundament. En af disse andre metoder er tests integreret direkte i koden, som tjekker for inkonsistente mellemresultater. Evaluering af den endelige alignment tager, som sagt, udgangspunkt i kvaliteten i forhold til en given reference. Såfremt en fejl er lavet, kan det forventes at kvaliteten vil falde. Ud over et kvalitetsmål fra afsnit 6.2, har vi også benyttet visuel evaluering af alignments. Dette er gjort ved at benytte det illustrationsværktøj som er en del af Mauve. Selvom dette langt fra er en eksakt validering, giver det stadig mulighed for at spotte større fejl og mangler. 6.2 Alignmentkvalitet Det ønskes selvfølgelig at kvaliteten af den alignment vi producerer skal være så god som mulig. I dette tilfælde vil det sige en alignment, der så præcist som muligt, afspejler den bagvedliggende evolutionære historie. Som beskrevet i afsnit 2.4 er det svært at opnå en god kvalitet samtidig med at udførelsestid og hukommelsesforbrug er minimalt, da netop de ekstra beregninger gør det muligt at lave en mere velovervejet alignment. Derfor er vores mål at opsætte et kvalitetsmål til at evaluere hvorvidt vi enten er i stand til at forbedre kvaliteten, eller bevare den under optimering af tid og hukommelse. Der er dog en forskel på krav om kvalitet og øvrige krav, nemlig at kvaliteten nu engang kun er så god som den anvendte metode tillader, hvor tid og hukommelse kan kompenseres for ved at udnytte ekstra hardware. Det er af denne grund at vores fokus gentagende gange også har været på at kunne udnytte flere kerner frem for kun at optimere selve algoritmen. Et enkelt aspekt af en ankerbaseret alignment-metode vi ikke har diskuteret, som kan få stor betydning for kvaliteten, er variation af k-mer størrelsen. Denne er fastlagt til 15 for eksperimenter foretaget på mindre datasæt, hvilket er vurderet til at være en fornuftig størrelse ud fra [5] Kvalitetsscore Vi kiggede på hvordan Mauveartiklen [5] evaluerede deres alignments sammenlignet med andre programmer. Her konstaterer de, at der ikke er nogle manuelt

92 6.2. ALIGNMENTKVALITET 87 udarbejdet datasæt der tager højde for inversions og rearrangements, hvilket gør evaluering vanskeligt. Selve kvalitetsmålet for multiple alignment værktøjer (som dem i afsnit 2.4, benytter ofte sum-of-pairs som mål for kvaliteten [7, 15], hvilket også er tilfældet for Mauve. Sum-of-pairs går for disse helt ned på nukleotidniveau og måler hvor præcist insertions og deletions er placeret. Dette mener vi dog ikke er et specielt godt mål for global alignment af hele genomer, hvor identifikationen af LCB er er det primære mål. Ikke at den mere traditionelle multiple alignment for hver LCB ikke er vigtig, men at denne alignment er afhængig af hvor godt internt en LCB matcher. Da vi benytter et eksternt program til at foretage disse lokale multiple alignments internt i hver LCB, vil sum-of-pairs også i høj grad være et mål for hvor godt dette program håndterer opgaven. Vi vælger som en følge af ovenstående, at evaluere alignments efter samme ide som brugt i beskrivelsen af Progressive Mauve [4, afsnit 6.1]. Her opereres med to niveauer af kvalitetsmål. Dels kigges der på antallet af korrekt alignede nukleotider og dels på hvor mange LCB er der blot overlapper med mindst én nukleotid. Vi har valgt at lave en kombination af de to niveauer, hvor størrelsen af overlappet (se figur 6.1) evalueres mellem en reference LCB og en LCB produceret af et multiple alignment værktøj. Vi har derfor lavet et værktøj der sammenligner alignments på hvor stort et overlap der er mellem deres respektive LCB er. Vi kan nøjes med dette evaluerings værktøj, da vi i modsætning til Mauve og Progressive Mauve, har flere værktøjer at kunne sammenligne os med. Nemlig forskellige versioner af Mauve samt Shuffle-LAGAN. Desuden har vi lavet en sekvenssimulator (beskrevet i afsnit 6.7), som gør at vi har et bredt spektrum af metoder at sammenligne os med. I beskrivelsen af Progressive Mauve [4, afsnit 6.1] opereres der med to begreber, nemlig sensitivity og PPV (Positive Predictive Value), som tilsammen giver overblik over kvaliteten af en alignment. Sensitivity: PPV: T P T P+F P T P T P+F N I ovenstående er T P antallet af Sande Positive, F N er Falske Negative og F P er Falske Positive. Dette betyder for os, at sensitivity er et mål for hvor stor en del af vores LCB er, der overlapper med referencens LCB er. Med andre ord, hvor stor en del af referencen der bliver fundet. PPV angiver hvor stor en del af vores LCB er der også findes i referencen. Derfor ønskes begge værdier at være så høje som mulige, hvor 1,0 er maksimum. Sensitivity kan alene ikke give et godt mål for kvalitet, da eksempelvis en triviel alignment, hvor en LCB strækker sig over den fulde længde af sekvenserne, vil have en maksimal værdi. Derfor skal sensitivity altid ses i forhold til PPV.

93 88 KAPITEL 6. RESULTATER ÐÑÒÑÓÑÔÕÑ Ö Ø Ö Ø ÙÔÚÑÓ ÛÔÛÜÝÞÑ ßàáâã äåæàçèé êàëì íîâèçèé ßàáâã íîâèçèé Figur 6.1: Overlap mellem to LCB er giver anledning til kvalitetsscore Reference for kvalitetsmåling Vi benytter to typer af referencer når vi evaluerer kvaliteten af en alignment. For simulerede sekvenser genererer vi en reference som kan hjælpe os med at afgøre hvad en god alignment er. For reelle sekvenser benytter vi Progressive Mauve. Dette program omfatter i høj grad alle de teknikker vi har set hos andre program, tidligere versioner af Mauve samt vores egne teknikker. Valget af Progressive Mauve som reference bygger også på forsøg med simulerede sekvenser, hvor dette program opnår de bedste resultater. Følgende tabel viser gennemsnitsværdierne for sensitivity og PPV af de simulerede sekvenser som fremgår af afsnit Mauve 1.2 Mauve 2.3 Progressive Mauve Sensitivity 0,9557 0,9818 0,9867 PPV 0,9480 0,9465 0,9435 Det ses af tabellen at Progressive Mauve har højere sensitivity end de øvrige programmer. Denne ekstra sensitivity giver dog også Progressive Mauve en marginalt lavere PPV end de andre. Vi vurderer at selvom ingen af metoderne er helt præcise, så klarer Progressive Mauve sig bedst, og er et ganske fornuftigt program at bruge som reference. Derfor anvendes denne metode de steder hvor der ikke er tale om simulerede sekvenser og intet andet er nævnt. 6.3 Måling af hukommelsesforbrug At kigge på hukommelsesforbruget for vores implementering er interessant af flere grunde. Den vigtigste er, at mængden af hukommelse som er påkrævet for at foretage en alignment, helst skal være så lille, at det er muligt at færdiggøre den. Dette afhænger selvfølgelig af sekvenserne som ønskes alignet. Set i forhold til vores egen målsætning samt kravet fra CLC bio, skal vi kunne håndtere hele kromosomer, der kan være op til flere hundrede millioner nukleotider lange, på en maskine med 2 GB hukommelse. En anden grund til at minimere hukommelsesforbruget er, at det betyder at der går længere tid hvor hukommelse kan bruges, uden at disken skal tages i brug. Af denne grund forventes det også, at udførelsestiden i nogle tilfælde forbedres ved at minimere hukommelsesforbruget.

94 6.3. MÅLING AF HUKOMMELSESFORBRUG 89 Af ovenstående grunde ønsker vi at lave detaljerede undersøgelser af hukommelsesforbrugt for forskellige versioner af Mauve samt vores egne implementeringer. Sammenligningen med Mauve 2.3 giver os en generel ide om hvorvidt vi formår at holde hukommelsesforbruget nede, da det antages at Mauve 2.3 indeholder en række af hukommelses optimeringer lavet gennem de år Mauve har eksisteret. Mauve er skrevet i C++ og dermed kan hukommelsesforbruget måles løbende ved at forspørge styresystemet, hvilket vi konkret gør med kommandoen top på et Linux baseret operativsystem. Vi måler hukommelsesforbruget med et interval på 1000 ms. Vi bruger kolonnen VIRT fra top. Denne er ifølge top defineret som: The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out. Ved at bruge VIRT tæller vi også hukommelse for shared, swapped og biblioteker med. Vi vil som udgangspunkt ikke få brug for swap til vores tests, men at måle på VIRT kan give Java målingerne en fordel, hvis de biblioteker programmet afhænger af, fylder meget i hukommelsen. Dette burde dog være en relativ lille andel for de større tests, hvorfor vi godt mener det kan retfærdiggøres at bruge VIRT til måling af hukommelsesforbrug. For vores implementering der benytter Java er situationen anderledes. Java s VM har en garbage-collector, som er delt op i flere generationer, som hver først får frigjort hukommelse i det omfang det er nødvendigt [16]. Disse generationer indeholder forskellige objekter alt efter hvor lang tid de har eksisteret. Vi kan ikke spørge styresystemet om hvor meget hukommelse den pågældende JVM benytter, da der internt muligvis kun benyttes en del af den allokerede hukommelse. Vi har derfor instrumenteret vores kode således, at der sideløbende kører en tråd, som med faste intervaller prøver at fremtvinge en garbage-collection og efterfølgende forespørger JVM en om hvor meget hukommelse der anvendes. Konkret finder vi hukommelsesforbruget for Java på følgende vis: Runtime.gc(); Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory(); Vi er opmærksomme på at ovenstående ikke er garanteret til at fremtvinge en garbagecollection. Vi har dog gennem gentagelser af tests observeret den samme hukommelsesprofil, hvilket vi ser som en god indikator for, at vi rent faktisk får JVM en til at lave en garbage-collection. Såfremt det ikke altid skulle være tilfældet vil hukommelsesforbruget fremstå som større end det reelt er og derfor skal resultaterne fra Java ses med dette i tankerne. Målings intervallerne ændrer vi for hver fase af algoritmen. Faser der allokerer lidt hukommelse, men tager relativt lang tid, har længere intervaller. Grunden til at vi ændre disse intervaller er, at den hyppige kørsel af garbage-collectoren påvirker udførelsestiden. Selvom det ikke er udførelsestiden vi ønsker at sammenligne, er det stadig problematisk at udførelsestiden ændrer sig, da det gør det sværere at sammenligne hukommelsesforbruget for hver fase, med

95 90 KAPITEL 6. RESULTATER andre programmer. Dette problem blev gjort mindre ved at vi for forskellige faser varierede intervallet fra 100ms til 1000ms. Uanset hvor meget vi forsøger at kompensere for dette, er det ikke muligt at gøre resultaterne umiddelbart sammenlignelige. Derfor har vi indbygget en normalisering af tiden for hukommelsesmålinger. Dette foregår ved at vi først kører den pågældende metode mens vi udelukkende måler dens samlede tidsforbrug. Dette bruger vi så til, at skalere resultaterne fra hukommelsesmålingen, hvilket gør at varigheden for diverse faser af hver metode passer bedre med tiden. Dette kompenserer ikke for at nogle faser bliver mere påvirket end andre, men sørger for at det overordnede billede for hver metode er sammenlignelig. Eftersom CLC s framework har sine egne persisterings mekanismer, kan der ligge ting i hukommelsen der kun bliver garbage-collected, når CLC s framework tillader det. Derfor kan det nogle steder i graferne se ud som om, at vi bruger meget hukommelse, hvor det i virkeligheden er CLC cachen der venter med at lade data blive garbage-collected, i håb om at disse kan bruges senere. Altså har vi fundet en metode til måling af hukommelse, for både eksterne programmer og Java, som er nogenlunde retvisende. Der er dog enkelte forbehold, som vi bliver nødt til at inddrage i fortolkningen af resultaterne. 6.4 Måling af tidsforbrug For samtlige programmer har vi til evalueringen af tidsforbruget, brugt linux kommandoen time. Vi har med denne kommando både måle tid og gennemsnitlig CPU-udnyttelse. Eftersom maskinerne har været dedikeret til test-kørslerne er den reelle tid interessant, da den fortæller hvor lang tid man i praksis kan regne med en kørsel af programmet tager. CPU-udnyttelse og CPU-tid kan bruges som redskaber til at se hvor effektivt et program kan udnytte CPU en og hvor godt det kan udnytte flere kerner på en maskine. Især for vores implementeringer spiller det en stor rolle hvorvidt vi effektivt kan udnytte flere kerner og derved reducere den reelle tid brugt. For vores egne implementeringer har vi lavet et internt tidsmålingsmodul der kan give en deltid for hver enkelt fase. Dette er et redskab vi gentagende gange har brugt til at se hvordan ændringer påvirker udførelsestiden og danne os et overblik over hvilke faser der generelt bør optimere på, samt sikrer at optimeringerne opfører sig som forventet. 6.5 Testmaskiner Vi har brugt følgende maskiner undervejs i vores evaluering af tids- og hukommelsesforbrug.

96 6.6. VALG AF DATA 91 Betegnelse CPU Type Frekvens [GHz] Ram [GB] 8-kernet maskine Intel(R) Xeon(R) CPU X kernet maskine Intel(R) Core(TM)2 Quad CPU Q Begrænset VMware på Intel(R) Core(TM)2 4-kernet maskine Quad CPU Q kernet maskine Intel(R) Core(TM)2 Duo CPU E For sammenligning af tiden har vi primært brugt en 4-kernet maskine. Til måling af relative forbedringer af tiden samt måling af hukommelsesforbrug har vi både anvendt en 4-kernet og en 2-kernet maskine. Til de endelige tests på større datasæt, har vi anvendt den 8-kernede maskine, som er stillet til rådighed af CLC bio. 6.6 Valg af data Udvælgelse af sekvensdata er vanskeligt for en genomaligner. Ikke bare er der enorme mængder data at vælge imellem, men præcis hvilke data der udvælges, kan give anledning til forskellig opførsel for hvert program. Da der er tale om alignment mellem to eller flere sekvenser, er det ligeledes nødvendigt at finde data, som også giver mening at sammenligne hvilket yderligere komplicerer udvælgelsen. Vi har valgt at sekvenser fra både bakterier og eukaryoter bør kunne alignes og derfor også testes. Dette giver lidt forskellige krav til hvad der skal kunne håndteres, idet bakterier og eukaryoter varierer meget i eksempelvis længde og struktur. Vi har også genereret en række af datasæt for bedre at kunne kontrollere længden og have en tilhørende korrekt alignment. Hvert datasæt er navngivet med et specifikt id hvis detaljer fremgår af bilag C Bakterielle data Bakterier har typisk mindre genomer og større variation, sammenlignet med eukaryoter. Mauve blev udviklet med henblik på et konkret datasæt af bakterier der ønskedes undersøget. Derfor vil en sammenligning med Mauve også være baseret på samme datasæt, da vi i et vist omfang er inspireret af deres metode. Mauvesartiklen henviser til ni bakterielle genomer, som vi har fundet og benytter, som også fremgår af bilag C.1. Ud over at Mauve er blevet testet på disse data, finder vi dem også interessante, da der er tale om genomer fra tre forskellige organismer, nemlig E. coli, Shigella flexneri og Salmonella. Det interessante i dette datasæt er, at sekvenserne fra samme art er forholdsvis identiske, mens der er en stor forskel arterne imellem. Dette forventes at give en del udfordringer til alignment værktøjerne.

97 92 KAPITEL 6. RESULTATER Af praktiske årsager har vi også ønsket at have et mindre datasæt for tests af mellemliggende resultater. Dette gør den reelle udførelseshastighed lavere og gør det samtidigt nemmere at evaluere resultatet, da færre faktorer spiller ind. Vi har derfor udvalgt tre af bakterierne som fremgår af bilag C.1.1. Disse tre bakterier er udvalgt således at to af dem tilhører samme art hvor det sidste genom er fra en anden art. Der kunne argumenteres for mange andre udvælgelser, men med denne kombination forventes både forskelle og store ligheder at blive testet og illustreret. Vi har også udvalgt tre datasæt bestående af fire bakterier der prøver at teste forskellige aspekter af et alignment program. Disse datasæt fremgår af bilag C.1.2. Konkret prøver disse datasæt at teste både håndteringen af ankre parvist mellem sekvenser og præcisionen ved at have sekvenser der er fra samme art Eukaryotiske data Testdata for eukaryoter har vi udvalgt til at bestå af en række kromosomer fra menneske og mus. Konkret sammenligner vi kromosom X samt henholdsvis kromosom 4 og 5. Vi har klippet mindre områder ud fra disse kromosomer for at have data med variationer i længden. Detaljerne for disse datasæt fremgår af bilag C.2. Vi har udvalgt disse to organismer da de er meget interessante i forskningssammenhænge Simulerede data Ud over de ovenstående datasæt, baseret på rigtige genomer, har vi bygget en sekvenssimulator, der kan bruges til at supplere vores evaluering af alignment-værktøjerne. Ulempen ved at bruge rigtige genomer er, at der ikke findes nogen reference, der kan bruges til en korrekt vurdering af, hvilket værktøj der finder den bedste alignment. Det næste afsnit beskriver hvordan vi har implementeret vores sekvenssimulator, samt hvordan vi har brugt den til at evaluere alignment værktøjer. De generede datasæt kan ses på bilag C Udvikling af sekvenssimulator Vores sekvenssimulator er udviklet i Java, som et selvstændigt program, der er adskilt fra resten af vores projekt. Sekvenssimulatoren laver sit output i Mauves XFMA format, hvilket er gjort for at gøre det lettere, at sammenligne på tværs af de forskellige alignment-værktøjer Designvalg for sekvenssimulator For at lave en sekvenssimulator, var det først nødvendigt at lave en række af valg angående kompleksiteten af simulatoren, der skal bruges til at målrette udviklingen.

98 6.7. UDVIKLING AF SEKVENSSIMULATOR 93 Det første valg var hvilken model for evolution vi skulle benytte. En mulighed var, at bruge en Hidden Markov Model (HMM), som er en statistisk model. En HMM kan bruges til at lave en sekvens med forskellige områder, hvor hvert område har sin egen nukleotid frekvens. En sådan model vil kunne bruges til både generering af en dna-sekvens samt, at lave mutationer, insertions og deletions i sekvensen (de såkaldte small-scale-events, beskrevet i kapitel 2.1). Herefter kan en anden model bruges til at lave large-scale-events. Dette vil dog være en meget omfattende model at implementere, og i de værktøjer vi betragter er der ikke taget noget speciel hensyn til, områder med forskelligt antal af small-scale-events. Vi har således taget en mere simpel løsning, hvor vi bruger en eksisterende dna-sekvens fra en organisme, som reference, til at lave k sekvenser med både small- og large-scale-events. Endvidere har vi valgt at distribuere hændelserne uniformt, da dette yderligere simplificere implementeringen Implementering Sekvenssimulatoren har følgende trin i transformationen af en reference dna-sekvens til k forskellige sekvenser med både small og large-scale-events: Referencesekvensen bruges til at lave k nye sekvenser, der alle indledningsvis er identiske. Der foretages en række af small-scale-events i sekvenserne. Der laves efterfølgende large-scale-events bestående af følgende begivenheder: rearrangements og inversions. Der foretages igen en række af small-scale-events i sekvenserne. Undervejs i de ovenstående trin er alle events blevet registreret. Disse bruges nu til at opbygge LCB er der giver en afbildning af nukleotiderne i de forskellige sekvenser. LCB er kan godt være mellem en delmængde af sekvenser. Metoden for at danne LCB er bliver beskrevet senere. Der udskrives nu en XFMA alignment og algoritmen er færdig. Opbygning af LCB er ud fra event beskrivelse For hver sekvens gemmes en liste over hvordan nukleotiderne er placeret i forhold til referencesekvensen. Følgende viser et eksempel for to sekvenser: Reference: A C T G A C T G A Rækkefølge:

99 94 KAPITEL 6. RESULTATER Sekvens1: G A A C T T T T A C T Rækkefølge: Sekvens2: A G T G A G C C G Rækkefølge Nu kan events detekteres på følgende måde: Rearrangement: Rækkefølgen er forskellig i en eller flere sekvenser, i forhold til resten. Insertion: I listen er der indsat -1. Hvis en insertion har en nukleotid på begge sider der matcher. Hvis en insertion sker mellem to LCB er giver en insertion ikke anledning til en ny LCB, da insertions ikke har noget meningsfyldt tilsvarende i nogle af de andre sekvenser. Deletion: Detekteres ved at der er en liste der mangler en del af rækkefølgen som eksisterer i de andre. Inversion: Rækkefølgen går i modsat retning. Mutation: Rækkefølgen er den samme mens nukleotiden er ændret. Hvis der kommer en insertion mellem to LCB er, bliver insertion ikke medtaget som del af en LCB, da insertion-sekvensen ikke udgør nogen kolineær blok. LCB opbygning Ud fra fremgangsmåde i forrige afsnit, giver tidligere eksempel anledning til følgende LCB er: LCB 1 LCB 2 Sekvens 1, Tegn 3-8: A C T T T T Sekvens 1, Tegn 2: A Sekvens 2, Tegn 3-1: A C T Sekvens 2, Tegn 9: G LCB 3: 5-6 Ikke inkluderet i nogen LCB Sekvens 1, Tegn 9-10: A C Sekvens 1, Tegn 1, 11: G, T Sekvens 2, Tegn 5-6: A G Sekvens 2, Tegn 4, 7-9: G, C C G LCB erne kan i nogle tilfælde blive så små, at det ikke kan forventes, at de i praksis kan detekteres. Dog kan værktøjet fint bruges til at lave en referencealignment, som kan bruges til at sammenligne andre værktøjer med hinanden.

100 6.7. UDVIKLING AF SEKVENSSIMULATOR Generering af datasæt med sekvenssimulatoren Eftersom vi ikke har brugt avancerede statistiske modeller til sekvenssimulatoren, har vi været nødt til at have en empirisk tilgang til estimering af parametre til generering af datasæt. Vi valgte at bruge Mauve, Progressive Mauve samt Mauves visualiseringsværktøj til at vælge parametrene. Først laves et konservativt estimat af hvorledes værdierne for hver parameter skal sættes. Efterfølgende genereres datasættet vha. sekvenssimulatoren givet de valgte parametre. Datasættet alignes med Progressive Mauve og Mauve 2.3. Alignment sammenlignes vha. Mauves visualiseringsværktøj, med en alignment for tre bakterier. Såfremt alignment en ikke visuelt ligner en alignment for tre bakterier, gentages processen med justerede parametre. Når der er fundet et antal gode datasæt, bruges interpolering til at udfylde parametre for de mellemliggende datasæt. Ovenstående fremgangsmåde har resulteret i følgende parametre for data mellem 0.5 og 5 mbp i længde: Smårearrangementrearrangementinsertioninsertiondeletions Store- Store- Små- Store- Længde Mutationsrate [mbp] ( mbp) ( mbp) ( bp) (2-50 bp) ( bp) Vi har brugt både et bakterielt og humant genom som reference til generering af datasæt (Se bilag C.3 for en mere detaljeret gennemgang af referencesekvenser samt generede datasæt). Ved at have to forskellige referencer, har vi mulighed for at bedømme hvor stor indvirkning selve referencen har, for alignment-værktøjernes evne, til korrekt at finde ens regioner mellem sekvenserne. Sekvenssimulatoren er lavet forholdsvis ineffektivt, hvorfor vi ikke har haft mulighed for at generere større datasæt.

101 96 KAPITEL 6. RESULTATER Evaluering af sekvenssimulatoren Figur 6.2 viser hvordan et genereret datasæt, ligner et rigtigt, når det alignes vha. Mauve. For at kontrollere at vi ikke har en for lav eller for høj mængde af events, i forhold til et bakteriegenom, har vi målt kvaliteten og udførelsestiden for Mauve på datasættet 3bac og det generede 4.5 mbp datasæt (3bsim5) med en bakteriereference. Sammenligning af kvaliteten og udførelsestiden ser vi som et udtryk for at sekvenser er forholdsvis ens fra en genom-aligners perspektiv. Først har vi set på om der er et stort udsving i kvaliteten mellem Mauve 2.3 og Progressive Mauve, på de to datasæt. Vi har brugt Progressive Mauve som reference sammenlignet med Mauve 2.3 Datasæt Sensitivity PPV 3bac bsim Kvalitetsmålingen antyder at 3bac har en lidt højere kompleksitet end det generede datasæt. Den primære forklaring er nok, at vi ikke har ret mange LCB er der kun er i en delmængde af sekvenserne, i forhold til 3bac. Eftersom Progressive Mauve kan finde delmængde MUM s i modsætning til Mauve 2.3, giver dette anledning til en større forskel på 3bac. Efterfølgende har vi set på udførelsestiden: Program Datasæt Tid [s] Mauve 2.3 3bac 126 Mauve 2.3 3bsim5 144 Progressive Mauve 3bac 146 Progressive Mauve 3bsim5 127 Forskellen mellem de to kørsler af Mauve 2.3 er forårsaget af, at datasættet 3bac har lidt længere sekvenser end det genererede datasæt. Den større forskel set på Progressive Mauve har samme årsag som før, hvor der er flere delmængde MUM s der skal håndteres. Eftersom generering af datasæt, er fyldt med brugerdefinerede parametre, vil vi primært bruge disse datasæt som en bekræftelse af vores observationer på reelle data, frem for som de primære. Ind til nu i dette kapitel har vi kigget på hvordan vi generelt har evalueret vores implementeringer. I næste afsnit laves der en grundig evaluering af Final og Final- Pash.

102 6.7. UDVIKLING AF SEKVENSSIMULATOR 97 Alignment af tre bakteriegenomer med Mauve NC_ fasta NC_ fasta NC_ fasta Alignment af tre genererede bakteriegenomer med Mauve TestLen Mut0.02Seq3ID6329 Seq1.fasta TestLen Mut0.02Seq3ID6329 Seq2.fasta TestLen Mut0.02Seq3ID6329 Seq3.fasta Referencealignment for de tre generede genomer TestLen Mut0.02Seq3ID6329 Seq1.fasta TestLen Mut0.02Seq3ID6329 Seq2.fasta TestLen Mut0.02Seq3ID6329 Seq3.fasta Figur 6.2: Øverst ses en alignment for tre rigtige bakteriegenomer. Næstøverst ses en alignment for tre generede bakteriegenomer lavet af Progressive Mauve. Nederst ses en referencealignment hvor LCB er afspejler de faktiske events i genomet.

103 98 KAPITEL 6. RESULTATER 6.8 Endelige resultater og evaluering I dette afsnit udvider vi vores evaluering til at omfatte følgende algoritmer: Final og Final-Pash (Final hvor Pash er brugt til den indledende ankersøgning), Draft, Mauve 1.2, Mauve 2.3, Progressive Mauve og Shuffle-LAGAN. Vores primære fokus er, at evaluere hvordan vores endelige implementering, Final og Final-Pash, forholder sig til disse programmer. Endvidere ser vi på, hvorvidt vi har nået vores målsætning om, at kunne aligne hele kromosomer på en almindelig workstation. Først betragter vi nogle aspekter omkring korrektheden af vores endelige udgave. Efterfølgende kigges der på resultater for kvaliteten, hukommelsesforbruget og tidsforbruget, hvor vi inddrager alle de nævnte programmer Evaluering af korrekthed for Final I vores endelige udgave har vi introduceret både nye ideer og optimeringer. Vi har brugt følgende fremgangsmåde til at evaluere, om vi løbende havde et funktionelt program, der giver et gyldigt output. Vi har genbrugt rækken af unit tests fra vores Draft udgave, der har verificeret at vores faser stadig har et korrekt output. Desuden har vi en række af interne tjek vi kan slå til, der verificerer at der ikke er inkonsistens undervejs i algoritmen. Ingen af ovenstående metoder er dog i sig selv fyldestgørende, så vi har endvidere sørget for at evaluere programmet på forskellige datasæt og set at der ikke er forekommet nogle uforklarlige udsving i hverken kvalitet, udførelsestid eller hukommelsesforbrug. Vi har her sammenlignet med vores Draft udgave og forskellige udgaver af Mauve Evaluering af kvalitet Evalueringen af kvalitet vil delvist være baseret på de samme datasæt, som også blev brugt i evalueringen af Prototype og Draft. Men vi vil også inddrage nogle ekstra datasæt, hvor alignment er muliggjort af de hastighedsoptimeringer vi har foretaget i Final udgaven. Det skal bemærkes at Final-Pash kun kan indgå de steder, hvor netop to sekvenser alignes. Der er primært to ændringer for vores endelige udgave, der gør at den kan adskille sig i kvalitet fra vores Draft udgave. Dette drejer sig om den mere aggressive alignment-strategi for Final, som beskrevet i afsnit 5.3.5, og Pash, som beskrevet i afsnit 5.1. Resultaterne for tre bakteriegenomer (3bac) og tre simulerede bakteriegenomer (3bsim5) fremgår af tabel 6.1 og 6.2. Det ses at der er sket en forbedring i Final udgaven i forhold til Draft på det første datasæt med tre bakterier. For det genererede datasæt med bakterie reference, er der ikke sket nogen nævneværdig forbedring.

104 6.8. ENDELIGE RESULTATER OG EVALUERING 99 Kvalitet for datasæt med tre bakterier Draft Final Mauve 1.2 Mauve 2.3 Sensitivity 0,9205 0,9425 0,9300 0,9480 PPV 0,9989 0,9980 0,9983 0,9954 Tabel 6.1: Kvaliteten for datasæt med tre bakterier (3bac). Der ses en forbedring fra vores Draft til Final udgave, således at kvaliteten nu er bedre end Mauve 1.2 og næsten på højde med Mauve 2.3. Kvalitet for genereret datasæt med tre bakterier Draft Final Mauve 1.2 Mauve 2.3 Progressive Mauve Sensitivity 0,9633 0,9635 0,9612 0,9850 0,9987 PPV 0,9982 0,9987 0,9977 0,9978 0,9978 Tabel 6.2: Kvaliteten for 3bsim5 datasættet er stort set den samme for Draft, Final og Mauve 1.2. Der er også blevet testet på et andet genereret datasæt, der har brugt en human reference (3msim5). Datasættet viser samme tendens som tidligere, dog har alle programmer en lidt lavere score, formentlig forårsaget af, at dette datasæt har flere repeats. Vi har af denne grund ikke inkluderet en tabel for resultatet. Altså bekræfter evalueringen, at brugen af aggressiv alignment-strategi generelt giver anledning til højere sensitivitet end Draft-udgaven og Mauve 1.2. For at kunne perspektivere til Shuffle-LAGAN og Final-Pash har vi kørt på nogle af de samme datasæt, hvor vi kun betragter to af sekvenserne. Resultatet af disse sammenligninger fremgår af tabel 6.3 og 6.4. Af tabellerne kan det først bemærkes at Final-Pash enten opnår samme eller lidt lavere kvalitet end Final. Dette fald skyldes at Pash kun garanterer at ankre er unikke for hver hashtabel frem for globalt, hvilket ikke er en fordelagtig strategi, for små nærtbeslægtede sekvenser. Shuffle- LAGAN har desværre ikke været i stand til at køre på nogle af de bakterielle datasæt, da disse får programmet til at gå ned. Vi har således kun testet Shuffle-LAGAN på det simulerede datasæt. Her ses det, at kvaliteten er meget langt fra på niveau med de øvrige. Dette kan være en indirekte konsekvens af, at vores kvalitetsmåling betragter opdelingen i kolinære blokke, hvor Shuffle-LAGAN primært fokuserer på den mere traditionel multiple alignment og håndterer således ikke alle large-scaleevents fornuftigt. Det skal dog nævnes at Shuffle-LAGAN har en høj PPV, der indikerer, at det den trods alt finder, er korrekt. Vi har også lavet en test på ni bakterier (9bac). Dette datasæt er også brugt i Mauveartiklen [5], og er således et datasæt man må forvente, at Mauve 1.2 håndterer godt. Vi vil bruge dette datasæt til yderligere at afgøre hvorvidt vi har nået vores målsætning, om at have en metode der er fuldt på højde med Mauve 1.2. Kvaliteten for datasættet med ni bakterier fremgår af figur 6.5. Det ses at vi fuldt ud har nået

105 100 KAPITEL 6. RESULTATER Tabel 6.3: Kvaliteten for 3bac datasættet, hvor kun to sekvenser er evalueret for at kunne medtage Final-Pash og Shuffle-LAGAN. Shuffle-LAGAN gav en fejl for både dette og øvrige alternative datasæt vi prøvede og er derfor ikke inkluderet. Kvalitet for datasæt med to bakterier Draft Final Final- Shuffle- Mauve Mauve Pash LAGAN Sensitivity 0,8768 0,9146 0,8966 n/a 0,9051 0,9356 PPV 0,9994 0,9994 0,9994 n/a 0,9993 0,9990 Kvalitet for genereret datasæt med to bakterier Draft Final Final- Shuffle- Mauve Mauve Progressive Pash LAGAN Mauve Sensitivity 0,9775 0,9766 0,9761 0,4471 0,9823 0,9941 0,9816 PPV 0,9977 0,9977 0,9981 0,9951 0,9974 0,9974 0,9976 Tabel 6.4: Kvaliteten for to sekvenser fra 3bsim5 datasættet. Dette er gjort igen for at kunne medtage Final-Pash og Shuffle-LAGAN. Kvalitet for ni bakterier Final Mauve 1.2 Mauve 2.3 Sensitivity 0,8542 0,8360 0,8608 PPV 0,9906 0,9921 0,9908 Tabel 6.5: Test af kvaliteten for ni bakterier. Denne test indgik som en af formålene med Mauvealgoritmen i [5] (svarende til Mauve 1.2 implementeringen). vores målsætningen, om at kunne producere alignments af samme eller bedre kvalitet end Mauve 1.2. Vi har således en metode, der er fuldt ud praktisk anvendeligt med hensyn til kvaliteten, til alignment af bakteriegenomer. Det sidste aspekt af kvaliteten vi har kigget på, er hvordan vi klare os på alignment af hele kromosomer. Vi har til dette formål udvalgt kromosom X fra menneske og mus. Det at sammenligne så store sekvenser fra eukaryotiske organismer, forventes at være væsentlig anderledes end det at aligne bakteriegenomer. Dels forventes der repetitive områder i sekvensen, og dels områder i sekvenserne, der ikke er homologe, og af denne grund ikke kan alignes. Grundet størrelsen på kromosomerne, ca. 145 mega basepar, har vi sat k-mer størrelsen op til 22. Eksperimenter for en k-mer størrelse på 15, viste nemlig at det var svært at finde unikke ankre i så store sekvenser. Valget faldt på netop 22, da både højere og lavere værdier gav anledning til lavere kvalitet. Kvalitetsmålinger fremgår af tabel 6.6. Det bemærkes at Mauve 1.2 ikke er inkluderet, da algoritmen ikke skalerer tidsmæssigt til så store sekvenser. Af tabellen ses, at vores endelige implementering har betydelig lavere kvalitet end referencen, som er lavet med Progressive Mauve. Vores Final-Pash udgave klarer sig dog noget bedre

106 6.8. ENDELIGE RESULTATER OG EVALUERING 101 Kvalitet for kromosom X, hvor k = 22 Final Final-Pash Final-Pash Skip60 Mauve 2.3 Sensitivity 0,5426 0,7292 0,7302 0,9518 PPV 0,9853 0,9462 0,9448 0,9256 Tabel 6.6: Test af kvaliteten for kromosom X for menneske og mus. Der er brugt en k-mer størrelse på 22 da at en værdi på 15 viste problemer med at finde unikke ankre i så stort et datasæt. end Final. Det er uventet at vores endelige udgave klarer sig dårligere end de nyere versioner af Mauve, taget de tidligere resultater i betragtning. En del af årsagen skal formegentligt findes i, at de nyere Mauve versioner understøtter ikkeeksakte MUM s, som kan hjælpe med at finde flere MUM s for dette datasæt. Brugen af Pash til den indledende ankersøgning giver her en fordel i forhold til seed-and-extend. Tabel 6.6 viser også at Final-Pash opnår en lavere PPV, modsat seed-and-extend, som kan skyldes at den ikke kræver unikke k-mers og således kan gruppere nogle k-mers sammen, uden at de har noget evolutionært slægtskab. Eftersom Mauve 2.3 har en endnu lavere PPV end Final-Pash, kan det også være tegn på at der ikke er enighed om hvad en god alignment af de to kromosomer er og at tallene for PPV og sensitivity ikke skal ses som det endelige resultat. Final-Pash Skip 60, hvor der kun foretages 40% af iterationerne i Pash, klarer sig på niveau med Final-Pash. Dette skyldes at Pash stadig finder de bedste ankre, og seed-and-extend er i stand til at finde de resterende ankre, i en senere fase. Samlet set ligner det at seed-and-extend, der bruges for Final ikke er særlig godt egnet til meget store sekvenser og at krav om globalt unikke ankre kan være kraftigt begrænsende. Da Mauve 2.3 for kromosom X får næsten samme kvalitet som Progressive Mauve tyder det på at understøttelse af ikkeeksakte ankre sammen med andre ændringer af ankersøgningen, er årsagen til, at Final og Final-Pash ikke helt klare sig så godt. Gennem evalueringen af vores endelige udgave ses det, at vores metode indeholder fremskridt sammenlignet med Mauve 1.2. Mauve 2.3 og Progressive Mauve klare sig endnu bedre, hvilket også er at forvente, eftersom de indeholder en del videreudvikling af den oprindelige Mauve. Vi har forsøgt at anvende datasæt fra både bakterier og eukaryoter samt genererede datasæt. Der ses store udsving i kvaliteten når der kigges på forskellige typer af datasæt og derfor er det svært at udtale sig om hvordan vores metode klarer sig på alle typer af data. Det vi kan slutte er dog, at vi har klaret os godt sammenlignet med Mauve, på de datasæt, der udgør den type af data, Mauve blev udviklet til at kunne aligne. Dog havde vi lidt lavere kvalitet for meget store datasæt, hvor MUM s ligger langt fra hinanden.

107 102 KAPITEL 6. RESULTATER Final Final-Pash Mauve-1.2 Mauve-2.3 ProgressiveMauve Hukommelsesforbrug over tid Hukommelse [mb] Tid [procent af samlet tid] Figur 6.3: Hukommelsesforbruget for Final med og uden Pash sammenlignet med forskellige versioner af Mauve. Det ses at vi for større sekvenser har et fornuftigt hukommelsesforbrug sammenlignet med selv Mauve Evaluering af hukommelsesforbrug Vi har for evalueringen af hukommelsesforbruget valgt at fokusere på et enkelt stort datasæt på 33 MB (2mam33). Dette skyldes, at det for mindre datasæt, er svært at se nogen forskel i hukommelsesforbruget og desuden virker Final-Pash kun på to sekvenser. Da vores Final udgave ikke indeholder nogle ændringer der adskiller hukommelsesforbruget radikalt fra Draft, har vi udeladt Draft fra evalueringen. Den mindre forskel i hukommelsesforbruget for Final, fremgår allerede af afsnit Hvad angår Shuffle-LAGAN, har vi igen været nødsaget til at udelade denne fra evalueringen, da programmet kun kan aligne meget små sekvenser. Vi kan dog konkludere at Shuffle-LAGAN brugte over 3 GB hukommelse for et datasæt på omkring 5 MB, hvorfor den langt overstiger alle de andre algoritmer vi sammenligner os med i hukommelsesforbrug. En graf fremgår af figur 6.3 og viser som for Draft, hukommelsesforbruget uden parallelisering. Det ses at nu hvor det er muligt at aligne større datasæt end for Draft, skalerer hukommelsesforbruget for vores implementering betydeligt bedre end de fleste versioner af Mauve. Seed-and-extend delen af Final på figuren, bruger i samme størrelsesorden som Mauve 2.3 og Progressive Mauve. Pash formår at

108 6.8. ENDELIGE RESULTATER OG EVALUERING 103 holde hukommelsesforbruget stabilt og lavere end nogle andre, af de undersøgte programmer. Det ses også, at Mauve 1.2 skalerer meget dårligt på dette datasæt. Det skal dog noteres, at når dele af vores algoritme parallelisere, kræves der tilsvarende mere hukommelse. Vi vil sidst i afsnit evaluere mere på, hvordan vores algoritme opfører sig, når den køres på et endnu større datasæt, på en maskine med en begrænset mængde af ram Evaluering af tidsforbrug I dette afsnit kigger vi på hvordan vores udførelsestid for Final og Final-Pash forholder sig sammenlignet med Draft, Mauve og Shuffle-LAGAN. Første kigger vi på hvordan vi skalerer til flere sekvenser. Efterfølgende kigger vi detaljeret på, hvordan vi skalerer som længden af sekvenserne forøges. Til sidst analyseres tidsforbruget ved alignment af hele kromosomer. Skalering til flere sekvenser Vi har først evalueret på hvordan vores algoritme klarer sig, når mange sekvenser alignes samtidigt. Allerede i vores Draft udgave var vi, takket være vores parallelisering, hurtigere end Mauve 1.2 for fem bakteriegenomer. Vi har for Final udgaven udvidet evalueringen til at omfatte et datasæt med ni bakteriegenomer (9bac). Datasættet er kørt på en maskine med 8-kerner. En graf over udviklingen i udførelsestiden, som antallet af genomer øges, kan ses på figur 6.4. En mere detaljeret sammenligningen for alle ni bakterier, fremgår af figur 6.5. Det ses tydeligt af begge grafer, at vi er hurtigere end alle versioner af Mauve. Dette er som forventet og skyldes at seed-and-extend algoritmen, kan paralleliseres for både den indledende ankersøgning samt for intern og ekstern ankersøgning. Mauve 1.2 er udeladt for denne evaluering, da der ikke er en 64-bit version tilgængelig, som er nødvendig, for at kunne køre på den pågældende maskine. Selvom Mauve 1.2 ikke er inkluderet, har forsøg på andre maskiner vist, at Mauve 1.2 er langsommere end de nyere Mauve versioner også på dette datasæt. Vi slutter ud fra ovenstående at det i høj grad er lykkedes os at parallelisere store dele af algoritmen til håndtering af mange sekvenser. Dele af paralleliseringen skalerer i det omfang der alignes flere sekvenser og når det er tilfældet, er vi hurtigere end selv de nyeste versioner af Mauve. Variation af sekvenslængde Der er blevet lavet et større antal af optimeringer for Final, der giver et lavere tidsforbrug i forhold til Draft. Vi vil nu evaluere optimeringerne samlet og teste hvordan vi skalerer i forhold til sekvenslængden, sammenlignet med Draft og andre programmer. Der er anvendt fragmenter af forskellig længde fra kromosom X samt

109 104 KAPITEL 6. RESULTATER Undersøgelse af tidsforbrug ved alignment af op til ni bakterier Final ProgressiveMauve Mauve Tid (sek) Antal sekvenser Figur 6.4: Tid på CLC s 8-kernet maskine for en alignment af to til ni bakterielle genomer. Det ses at Final skalerer bedst, så længe der er færre eller samme antal sekvenser, som der er kerner på maskinen. óôõ ö ôøù òð úûüýþ Tidsforbrug for alignment af ni bakterier, opdelt efter faser úûüýþ ñð ÿý ýþ ü ü ý ïð ð ýþ ý ï! û ý ü ý ÿ ý û ü þ ýü û " #ý # ü Figur 6.5: Samlet tid på CLC s 8-kernet maskine for alignment af ni bakterielle genomer. Her opnår Final den hurtigste udførelsestid. Det ses også at hver fase i Final bruger stort set lige meget tid. Det understreger at det er lykkedes at parallelisere hver fase i tilfælde som dette hvor der haves adskillige sekvenser.

110 6.8. ENDELIGE RESULTATER OG EVALUERING Udførelsestid ved forskellige sekvenslængder Final Mauve-2.3 Final-Pash ProgressiveMauve Draft Mauve Tid (sek) Laengde (mbp) Figur 6.6: Variation af sekvenslængden kørt på forskellige programmer. Det ses at Draft og Mauve 1.2 skalerer meget dårligt og derfor er udeladt for større sekvenser. Mauve 2.3 er konsekvent det hurtigste program dog terminerede det ikke for det største datasæt. Udførelsestid ved forskellige sekvenslængder uden endelig alignment Final-noalign Mauve-2.3-noalign Final-Pash-noalign ProgressiveMauve-noalign Draft-noalign Mauve-1.2-noalign 3000 Tid (sek) Laengde (mbp) Figur 6.7: Variation af sekvenslængden for forskellige programmer hvor den endelig alignment er udeladt. Udførelsestiden opfører sig meget ens med den observeret inklusiv alignment og derfor ligner det ikke at den endelige alignment er helt så stort et problem da vi har formået at parallelisere fasen kraftigt.

111 106 KAPITEL 6. RESULTATER henholdsvis kromosom 4 og 5 for menneske og mus. Programmerne er kørt på en 8- kernet maskine, dog med undtagelse af Mauve 1.2, der er blevet kørt på en 4-kernet maskine med 32-bit understøttelse, for at vise den generelle tendens i udviklingen af udførelsestiden. Først ses der af figur 6.6 hvordan udførelsestiden forholder sig. Der mangler nogle målinger for Draft og Mauve 1.2, som er udeladt grundet en meget høj udførelsestid. Figuren viser at både Draft og Mauve 1.2 skalerer meget dårligt. Udførelsestiden stiger nogenlunde ens for vores endelige udgave samt nyere udgaver af Mauve. Der forekommer et knæk i grafen for Final og Final-Pash efter 20 MB, som vil blive analyseret senere i dette afsnit. Vi har også lavet en evaluering, hvor vi har udeladt den sidste fase, hvor der kaldes et ekstern alignment-program. Eftersom nyere versioner af Mauve har indbygget Muscle, kan disse spare en del tid på alignment-fasen. Af figur 6.7 fremgår det nærmere, hvordan de øvrige faser, for de forskellige programmer, klarer sig i forhold til hinanden. Programmerne har hver især stort set samme udviklingstendens som før, dog er der nu noget mindre tidsforskel mellem programmerne indbyrdes. Final-Pash klarer sig nu bedre end Mauve 2.3, hvilket antyder, at de nyere versioner af Mauve har fået effektiviseret alignment-fasen betydeligt. Figur 6.8 og figur 6.9 viser en nærmere analyse af hvordan hver fase i henholdsvis Final og Final-Pash opfører sig, som funktion af sekvenslængden. For Final ses samlet en nogenlunde jævn skalering af hver fase. Det udsving der tidligere blev observeret ved skiftet fra 20 MB til 26 MB fremgår også her og det ses at intern ankersøgning og gapped alignment er de faser der bruger ekstra tid. Det at intern ankersøgning ikke bruger markant mere tid for de større sekvenser viser at, der ikke er tale om et skaleringsproblem, men at det er tale om en forskel i de anvendte datasæt. Dette bekræftes endvidere af, at samme tendens ses for gapped alignment fasen, der bruger de samme områder som også bruges af den interne ankersøgning. Grafen for Final-Pash viser at Pash i sig selv bruger mindre tid på at finde MUM s. Pash giver her desuden anledning til, at de efterfølgende faser bruger mindre tid. Dette skyldes at Pash finder flere MUM s og derfor efterlader mindre arbejde. Pash viser sig derfor at være en god løsning, når der kigges på to sekvenser. Samlet set skalerer Final og Final-Pash fornuftigt i forhold til Mauve, hvilket primært er opnået gennem parallelisering. Der er ikke tale om en udførelsestid helt så hurtig som Mauve 2.3 til trods for at dette program kan håndtere ikkeeksakte MUM s. Målet med at lave en implementering af en metode der er på højde med Mauve 1.2 er dog opnået fuldt ud.

112 6.8. ENDELIGE RESULTATER OG EVALUERING 107 Tidsforbrug for Final fordelt på faser $% &'(()* '+,-./).0 1.0)2. '.3)245-., )2. '.3)245-.,.- &2))*7 82)'3(9,.0 )+,/,.'0,9. E))*F'.*F)G0).* : : ;<=><$?@A$B< CD% Figur 6.8: En detaljeret oversigt af hvordan tidsforbruget forholder sig for hver fase i Final fremgår her. Det ses tydeligt at seed-and-extend har problemer med skaleringen, hvilket også var forventet da der kun alignes to sekvenser. Tidsforbrug for Final-Pash fordelt på faser NOP QROST MI LJ LI KJ KI HJ HI J UVWWXY VZ[\]^X]_ `]_Xa] V]bXacd\][]\ ebc_xa] V]bXacd\][]\ UaXXYf gaxvbwh[]_ XZ[^[]V_[h] tvcu I i HM KI KL Ki LL MJ jklmksnopsqpk QrsT Figur 6.9: Her ses en oversigt af tidsforbruget for Final-Pash. Sammenlignes denne med figur 6.8 ses det at Pash bruger væsentlig mindre tid på at finde MUM s. De efterfølgende faser tager også mindre tid selvom Pash ikke anvendes. Dette skyldes at Pash finder flere ankre og derfor mindre arbejde for de efterfølgende faser.

113 108 KAPITEL 6. RESULTATER Kørsel af store sekvenser Vi har testet Final, Final-Pash og nyere versioner af Mauve på hele kromosom X for menneske og mus. Disse resultater er ikke inkluderet i variation af sekvenslængde da den ville gøre det svært at se forskelle mellem de øvrige tests. Resultaterne fremgår af figur 6.10 og forsøgene er foretaget med en k-mer længde på 22. Af figuren ses det at Final ikke klare sig så godt som Final-Pash og Progressive Mauve, hvilket også var at forvente, da Final ikke kan parallelisere optimalt for to sekvenser. Der er yderligere to interessante observationer at gøre. Dels at Progressive Mauve er hurtigere end Final, modsat den tendens vi tidligere så ved variation af sekvenslængden og dels at den fase der tager længst tid er ekstern ankersøgning. Forklaringen på hvorfor Progressive Mauve er hurtig og vi bruger så lang tid på ekstern ankersøgning viser sig at være den samme. For datasættet med to kromosomer, så er der store områder uden MUM s og af denne grund bruger ekstern ankersøgning meget tid for hver iteration på at lave en global søgning i disse områder. Progressive Mauve har her en anden strategi, idet den kun forsøger at udvide LCB er i et vidst lokalt område og undgår dermed den langsomme globale søgning. En anden interessant observation af figur 6.10, som også set tidligere, er at den primære grund til at Final-Pash er hurtigere, er igen fordi Pash algoritmen finder en større mængde MUM s og derfor efterlader mindre arbejde til ekstern ankersøgning. Rent faktisk er Final-Pash nu lige så hurtig som Progressive Mauve. Mauve 2.3 er, som tidligere observeret, den hurtigste metode. Da vi ikke kender detaljer om hvordan denne metode eksempelvis foretager ekstern ankersøgning er det svært at kommentere på hvorfor denne metode er hurtigst af alle. Samlet set så kan Final og Final-Pash fint håndtere meget store sekvenser. Final- Pash egner sig bedst til dette formål og har en udførelsestid der kan konkurrere med Progressive Mauve. Vi observerede at ekstern ankersøgning bruger meget lang tid på at lave en global søgning, hvilket ikke virker som en fornuftig strategi for store sekvenser med få områder der matcher. Tidsforbrug ved kørsel på maskine med begrænset hukommelse Efter i forrige afsnit at have undersøgt udførelsestiden for kromosom X på en maskine med 72 GB hukommelse, vil vi i dette afsnit kigge på indflydelsen på udførelsestiden, når den tilgængelige mængde af hukommelse begrænses. Vi har til disse målinger brugt en 4-kernet maskine med 2 GB hukommelse til rådighed. Figur 6.11 viser hvordan udførelsestiden forholder sig under disse vilkår. Den endelige gapped alignment er udeladet. Dette skyldes at for at der er tilstrækkelig hukommelse ledig til Muscle, så er det for Java nødvendigt at begrænse mængden af hukommelse der stilles til rådighed for JVM en under hele forløbet. Mauve 2.3 og Progressive Mauve har Muscle indbygget og kan derfor bedre styre hukommelsesforbruget. Derfor var

114 6.8. ENDELIGE RESULTATER OG EVALUERING 109 Tidsforbrug for k = 22 fordelt på faser ~ ƒ z}wxw zywxw y wxw y{wxw yzwxw vwxw wxw wxw wxw šž ˆ šž ˆ œˆ šž ˆ œˆ ž Ž w Ÿˆ Œ z œ Œ Ž Œ Ÿˆ Œ ˆ Šˆ Œ ˆ Ž Œ Œ ˆ Œ Ž Œ ˆ Œ Ž Š ŒŒ Œˆ Ž Œ Ž Ž ˆ Ž Œ Ž Figur 6.10: Her ses tidsforbruget for alignment af menneske og mus kromosom X foretaget på en 8-kernet maskine. det nødvendigt at udelade denne fase for at give et ens sammenligningsgrundlag for de øvrige faser. Af figur 6.11 kan det umiddelbart observeres at både Final og Final-Pash er hurtigere end Progressive Mauve, men at Mauve 2.3 klare sig endnu bedre. Denne figur kan ikke direkte sammenlignes med dem fra forrige afsnit, da disse er udført på en virtuel maskine og med andet underlæggende hardware. Alligevel kan der laves flere relative observationer sammenlignet med figur For Final ses der rent faktisk en kraftig relativ hastighedsforbedring. Dette skyldes at Final ikke er specielt begrænset af kun 2 GB hukommelse og bliver hurtigere grundet den underlæggende hardware. Final-Pash var tidligere betydelig hurtigere end Final, men dette er ikke længere tilfældet. Selve Pash fasen tager betydelig længere tid. Dette har flere forklaringer da der nu ikke længere kan paralleliseres på 8-kerner, men rent faktisk kun 2-kerner. Selvom maskinen havde 4-kerner var det nemlig nødvendigt at reducere antallet grundet kun 2 GB hukommelse. Det skyldes også at Pash i højere omfang belaster garbage-collectoren som dermed ender med at brugere betydelig mere tid. Final-Pash er dog stadig hurtigere end Final, da den reducerer arbejdsbyrden for den efterfølgende eksterne ankersøgning. Betydningen for udførelsestiden for Mauve 2.3 er forholdsvis upåvirket, hvilket kan forklares ved at Mauve 2.3 har et minimalt forbrug af hukommelse som udgangspunkt.

115 110 KAPITEL 6. RESULTATER Tidsforbrug ved kørsel på maskine med begrænset hukommelse ± ²³ ª µ «¹º»¼º º½»¼¾ ÀºÁºÀ ª ½¾»¼º º½»¼¾ ÀºÁºÀ É È ÊÁº ÊÁº ËÌ ¾Í Î Ïл ªÑÈ Ì¼µÀ¼»¾¾Áл Î Ïл ü»»ÄŠƼ» ½ÇµÁº» ÁÒÁº Áµº Óº½»¼¾ ÀºÁºÀ Figur 6.11: Sammenligning af udførelsestiden for kromosom X fra menneske og mus på en 4-kernet maskine med 2 GB hukommelse. Forsøget er foretaget med en k-mer størrelse på 22. Progressive Mauve bliver forholdsvis langsommere. Dette sker til trods for at den underlæggende hardware ellers favoriserer Progressive Mauve med undtagelse af den begrænsede hukommelse. Af denne grund kan det sluttes at Progressive Mauve bliver mest påvirket af den begrænsede hukommelse. Det at kunne aligne store sekvenser, på en workstation med begrænset hukommelse, må siges i høj grad at være muligt for både Final og Final-Pash. Sammenlignet med Mauve klare vi os også forholdsvis godt, idet Mauve 1.2 slet ikke kan anvendes og ligger på niveau med Mauve 2.3 og Progressive Mauve. Dermed er vores oprindelige målsætning mere end opnået.

116 K A P I T E L 7 KONKLUSION OG FREMTIDIGT ARBEJDE 7.1 Konklusion Vi har til fulde nået vores overordnede målsætning, som var at implementere et værktøj til alignment af hele genomer. Mere præcist så har vi som ønsket udviklet en metode, der anvender centrale elementer af algoritmen som beskrevet i artiklen om Mauve og er sammenlignelig med, eller bedre end, den tilhørende implementering, hvad angår både udførelsestid og kvalitet. Herudover har vi tilføjet vores egne bidrag, som har været nødvendige for at nå vores målsætning om, at kunne håndtere hele kromosomer på selv ganske begrænsede maskiner. Alignment af hele kromosomer blev muliggjort i større omfang end det er muligt med Mauve 1.2, grundet vores reducerede udførelsestid og hukommelsesforbrug. Hvad angår udførelsestiden, er vores implementering sammenlignelig med de seneste versioner af Mauve, nemlig Mauve 2.3 og Progressive Mauve. Dette er blevet opnået gennem dels parallelisering af visse dele af algoritmen og dels inddragelse af andre algoritmer, som eksempelvis Pash. Kvalitetsmæssigt er vores metode ikke altid på niveau med Mauve 2.3 og Progressive Mauve, såfremt sekvenserne der ønsket alignet har undergået et større antal mutationer. Der er dog tale om understøttelse af ikkeeksakte ankre, som vores implementering også vil kunne udvides med. Vi har også formået, i højere omfang end Mauve 1.2 og på niveau med de nyere version af Mauve, at kunne håndtere store kromosomer på begrænset hardware. Dette er opnået gennem CLC bio s framework, der håndterer brug af disken, når der er mangel på hukommelse og integrationen med dette må derfor betegnes som 111

117 112 KAPITEL 7. KONKLUSION OG FREMTIDIGT ARBEJDE succesfuld. Brugen af Java til udviklingen har sikret et højt abstraktionsniveau og dermed har vi kunne holde fokus på det algoritmiske, fremfor at bruge tid på optimeringer på et lavere niveau. Vi har også haft ideelle forhold til at parallelisere algoritmen på CPU er med mere end én kerne. Eftersom CLC bio s Workbench også er skrevet i Java, har vi opnået en direkte integration af vores værktøj i denne. Dette medfører, som ønsket, at efterfølgende analyser, baseret på den producerede alignment, er direkte tilgængelige. Den iterative udviklingsproces af implementeringsforløbet, der resulterede i tre versioner, har virket godt. Ved at adskille de forskellige forløb, har vi haft mulighed for at forbedre en del af koden eller anvende nye algoritmer, uden at skulle bevare kompatibilitet med de tidligere versioner, men hvor vi stadig havde en reference at sammenligne med sideløbende. Evalueringen af udførelsestid, hukommelsesforbrug og kvalitet for hver implementering gav os mulighed for at udpege de steder af algoritmen, der krævede mest arbejde i næste iteration. Evalueringen af Prototypen gav os ideer om, hvilke dele af Mauve der havde brug for en effektiv datastruktur. Dette blev opnået i Draftimplementeringen, som algoritmisk indholdt en komplet implementering af Mauvealgoritmen. Med udgangspunkt i Draft identificerede vi steder i algoritmen, der rummede muligheder for ændringer der ligger ud over dem beskrevet i Mauveartiklen, og udgør således vores eget bidrag. Disse ændringer involverede brug af alternative algoritmer og datastrukturer. En del af ændringerne var optimeringerne, der gjorde at vores algoritme skalerede bedre til store sekvenser. Vi introducerede desuden Pash algoritmen, der gjorde det muligt at parallelisere den indledende ankersøgning. Pash viste sig at være hurtigere end den eksisterende seed-and-extend ved parallelisering på flere kerner, samt give en forbedring af den samlede kvalitet. Vores bidrag til Mauve algoritmen, er hvad der har gjort at vores endelige udgave er på niveau med de nyeste versioner af Mauve, og således i stand til at aligne kromosom X for menneske og mus i løbet af nogle få timer på en almindelig workstation PC. Måling af kvalitet har været et vanskeligt område. Vi har været begrænset af, at der ikke har været nogle algoritmer, der adskiller sig væsentligt, at sammenligne vores med. Ved at udvikle en sekvenssimulator har vi forsøgt at komme uden om denne begrænsning, men selv her blev vi nødt til at bruge Mauve til at guide valget af parametre. Sekvenssimulatoren har alligevel været værdifuld, da den har tilføjet endnu et perspektiv til evalueringen, til at bekræfte den tendens der blev observeret ved reelle datasæt. Derfor kan vi godt slutte, at vi har udviklet en metode til alignment af hele genomer der klare sig godt både tidsmæssigt og kvalitetsmæssigt i forhold til Mauve og er anvendelig i praksis til alignment af hele kromosomer.

118 7.2. FREMTIDIGT ARBEJDE Fremtidigt arbejde Der er to fokusområder der er lagt op til i det videre arbejde på vores implementering, nemlig forbedring af udførelsestid og kvalitet af alignment. Den første videreførelse tager udgangspunkt i vores nuværende implementering og kan øge udførelseshastigheden. Vi har identificeret, at ved store sekvenser, som eksempelvis hele kromosomer fra menneske og mus, er der store områder, der ikke er bevaret. Dette betyder, at der bruges meget tid på den eksterne ankersøgning, uden at der opnås en bedre alignment. En fremgangsmåde i samme retning som Progressive Mauve vil være mere passende. Denne ændringer består i at der ikke foretages en global søgning, men mere lokale søgninger omkring hver LCB. Her viser Progressive Mauve at det ikke giver anledning til store tab i kvaliteten. Et andet fokus kunne være på forbedring af kvaliteten af den endelige alignment. Den væsentligste forskel, hvad angår kvalitet, som vi har identificeret mellem vores alignmentmetode og Mauve 2.3, er muligheden for ikkeeksakte MUM s. Dette gør det muligt at identificere flere MUM s som især er en fordel for divergente genomer. Konsekvensen er at flere områder kan alignes og man kan være mere kritisk over for de MUM s der findes. Med udgangspunkt i egne eksperimenter, har vi set at det at betragte MUM s mellem delmængder af sekvenser også kan føre til en forbedring af kvaliteten for alignments. Vores eksperimentelle udgave fandt delmængde MUM s ved at sammenligne alle sekvenser samtidig. Her kunne man alternativt benytte Progressive Mauves fremgangsmåde, nemlig at sammenligne sekvenser parvist. Dette kan netop gøres effektivt med Pash, såfremt man har flere kerner til rådighed. 7.3 Taksigelser Christian Storm Nørgaard Pedersen som vejleder. Mikkel Nygaard Ravn og Roald Forsberg som kontaktpersoner hos CLC bio og for løbende feedback på udviklingsforløbet. Mads Sørensen og Anders Kabell Kristensen for feedback på specialet. 7.4 Kildekode Vores implementering samt kildekode er tilgængelig via følgende adresse: Denne zip-fil indeholder følgende: readme.txt: Forklaring af hvordan de forskellige udgaver køres. Final.jar: Vores Final som stand-alone udgave, der kan køres uafhængigt af CLC Workbench. Kildekoden er inkluderet i jar-filen. Draft.jar: Vores Draft og Prototype udgaver der begge er indeholdt i denne stand-

119 114 KAPITEL 7. KONKLUSION OG FREMTIDIGT ARBEJDE alone udgave. Kildekoden er ligeledes inkluderet i jar-filen. GlobalAligner.cpa: Plugin til CLC Workbench. Kræver betalings udgave af CLC Workbench eller CLC Developer Kit SequenceGenerator.jar og AlignmentScorer.jar: Vores sekvenssimulator og alignment evaluerings værktøj. Disse er beskrevet nærmere i readme filen. 7.5 Arbejdsfordeling Specialet er blevet til på følgende vis: Vi har i samarbejde fundet forskellige områder at arbejde på sideløbende. Undervejs i forløbet har vi rådført hinanden omkring fremgangsmåden for de enkelte arbejdsområder. For hvert område har en af os startet på afsnittet i specialet og den anden har efterfølgende gennemlæst, rettet og kommet med forslag til tilføjelser. Vi angiver i følgende tabel hvem der har haft hovedansvaret for de forskellige afsnit. Steder markeret som fælles er afsnit hvor vi begge har arbejdet med området så meget at det ikke giver mening at lave en opdeling. Beskrivelse Fælles Steffen Poul Kapitel 2 Teori X Afsnit 2.1 Evolution X Afsnit Alignments X Afsnit Mauve X Afsnit Progressive Mauve X Afsnit Shuffle-lagan X Kapitel 3 Prototype X Afsnit 3.4 Evaluering X Kapitel 4 Draft X Afsnit 4.6 Evaluering X Kapitel 5 Final X Afsnit 5.1 Pash X Afsnit 5.2 Subset X Afsnit 5.3 Final-optimeringer X Kapitel 6 Resultater X Afsnit 6.1 Korrekthed X Afsnit 6.2 Kvalitet X Afsnit 6.4 Tidstest X Afsnit 6.3 Hukommelse X Afsnit 6.6 Testdata X Afsnit 6.7 Sekvenssimulator X

120 B I L A G A SUPPLERENDE MATERIALE A.1 Antal genomer tilgængelig per år Ovenstående graf samt bagvedliggende data er tilgængelige via følgende link: 115