Jeg hadde dette spørsmålet fra en kandidatstudent i går, og jeg satt fast.
Hva skal jeg si? Hvorfor bruke en CRAM i stedet for en BAM?
-
Når er det lurt å bruke en CRAM i stedet for en BAM?
-
Når er det en dårlig idé?
Jeg hadde dette spørsmålet fra en kandidatstudent i går, og jeg satt fast.
Hva skal jeg si? Hvorfor bruke en CRAM i stedet for en BAM?
Når er det lurt å bruke en CRAM i stedet for en BAM?
Når er det en dårlig idé?
Opptaket av CRAM har gått ganske sakte. Java-programmer som bruker htsjdk (f.eks. Picard, IGV og GATK) har bare relativt nylig lagt til støtte for CRAM. Hvis du trenger å bruke en gammel versjon av dem av en veldig merkelig grunn, kan det hende at CRAM ikke støttes.
Det er mange programmer skrevet i python som bruker pysam til å åpne BAM-filer, og disse bør teoretisk sett , støtte CRAM. Problemet er at noen av funksjonene kan mislykkes, og man kan ikke anta at forfattere alltid har skrevet koden som er nødvendig for å håndtere dette. Jeg bruker deepTools som et eksempel, siden jeg er en av utviklerne. En av tingene med CRAM-filer er at de (som standard) er laget slik at du trenger et referansegenom for å konstruere sekvensfeltet i hver justering. Dette fungerer fint hvis du bruker et standardgenom (htslib, via pysam, kan hente mange standardgener fra nettet automatisk), men hvis du ikke er det, må du spesifisere en fasta-fil som skal brukes til dekompresjon. Hvert verktøy må da legge til et alternativ for dette. Med pysam 0.14 og htslib 1.7 kan dette omgås ved ikke å dekomprimere sekvensen, men atferd må uttrykkelig be om.
Et annet problem er at mange verktøy vil bruke funksjoner fra filindeksen, for eksempel .mapped
-tilbehøret, for å få antall kartlagte avlesninger i en fil. CRAM-filer inneholder veldig lite informasjon, så dette mislykkes. Derfor må verktøyforfattere se etter CRAM-filer og både utlede og formere denne informasjonen gjennom funksjonene deres hvis det er nødvendig. Dette kan være en tidkrevende oppgave (f.eks. Det tok meg et par dager å få dette implementert i deepTools). Relatert er samtools idxstats
ubrukelig på CRAM-filer, siden det ikke er noen statistikk lagret i indeksen.
Når det er sagt, er det sannsynlig at CRAMs sakte får aksept vil til slutt gjøre det standarden. Det er allerede et praktisk arkivformat, det er bare et spørsmål om tid før brukerne kan anta at de fleste analyseprogrammer er skrevet for å håndtere det.