Spørsmål:
Hvorfor skulle noen bruke en CRAM i stedet for en BAM?
EB2127
2018-02-26 06:16:32 UTC
view on stackexchange narkive permalink

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?

  1. Når er det lurt å bruke en CRAM i stedet for en BAM?

  2. Når er det en dårlig idé?

En svar:
Devon Ryan
2018-02-26 07:10:38 UTC
view on stackexchange narkive permalink
  1. Når du vil spare plass (dette kan være en betydelig besparelse). Inntil ganske nylig (samtools / htslib 1.7) støttet bare CRAM lange CIGAR-strenger.
  2. Hvis du trenger å garantere at et vilkårlig uklart nedstrømsprogram vil være i stand til å håndtere det.

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.

@EB2127 Hvis dette svaret løste problemet ditt, kan du ta et øyeblikk og [godta det] (http://bioinformatics.stackexchange.com/help/someone-answers) ved å klikke på haken til venstre.
@terdon Takk for påminnelsen. Jeg prøver normalt å la spørsmålet være åpent noen dager for andre svar :)


Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 3.0-lisensen den distribueres under.
Loading...