Vraag:
STAR-lange parameters voor het uitlijnen van RNA ONT-uitlezingen naar het genoom
aechchiki
2017-08-31 03:25:48 UTC
view on stackexchange narkive permalink

Zijn er voorgestelde parameters om ONT-reads af te stemmen op het referentiegenoom met behulp van STAR-long? Voorlopig heb ik de parameters gebruikt die hier worden voorgesteld, maar ik merkte een vreemd gedrag op.

Ik heb RNA-reads ( D. melanogaster ) van R7 en R9 stroomcellen, afzonderlijk. Ik heb er alleen voor gekozen om 2D leest in de categorie pass te analyseren.

Ik heb respectievelijk 113249 reads voor R7 en 40318 reads voor R9 . Ik heb die leesbewerkingen uitgelijnd en krijg (slechts!) 150 uniek toegewezen leesbewerkingen voor R7 -gegevens en 8017 uniek toegewezen leesbewerkingen voor R9 -gegevens. Ik heb geprobeerd dezelfde opdracht opnieuw uit te voeren op een andere server met een nieuwe compilatie, maar het uitvoerbestand is consistent met deze 150 keer gelezen.

Als ik hetzelfde echter uitlijn met GMAP, krijg ik 78016 uniek toegewezen leesbewerkingen voor R7 en 33523 uniek toegewezen leesbewerkingen voor R9 , dus ik vermoed dat er iets mis is gegaan tijdens de uitlijningsrun.

Ik ben me ervan bewust dat de twee mappers zich heel verschillend gedragen, STAR-long is preciezer en geeft er de voorkeur aan mappings van minder reads te rapporteren maar op betere loci, en GMAP is over het algemeen minder nauwkeurig en probeert het meeste van de leest maar op niet-zo-goede loci.

Ik vroeg me af of sommigen van jullie hier ervaring mee hadden en me de beste parameters konden voorstellen voor RNA-reads van ONT?

Ik denk dat mijn antwoord geschikter zou zijn als opmerking, maar dat kan ik niet. Ik weet niet zeker of die instelling van SE zinvol is, maar wat dan ook. Dit is niet noodzakelijk een oplossing voor het gedrag dat u ziet, maar ik zou willen voorstellen om https://github.com/lh3/minimap2 te proberen voor cDNA-seq-uitlijning.
Van mijn kant werkt STAR-long niet goed met luidruchtige reads. Het werkte vooral voor iso-seq omdat het foutenpercentage van iso-seq-uitlezingen veel lager is.
Een antwoord:
gringer
2018-01-17 11:00:30 UTC
view on stackexchange narkive permalink

Ik heb geweldige resultaten behaald met minimap2, vooral in combinatie met een voorbehandeling van Canu voor foutcorrectie (met minimap2 voor de read-to-read mapping ): 

  # correct leest ~ / install / canu / canu-1.6 / Linux-amd64 / bin / canu overlapper = minimap \ genomeSize = 100M minReadLength = 100 minOverlapLength = 30 -correct \ -p 4T1_BC06 -d 4T1_BC06 \ -nanopore-raw workspace / pass / barcode06 / fastq_runid _ *. Fastq # align leest ~ / install / minimap2 / minimap2 -p 10 \ -a ~ / db / fasta / mmus / ucsc / mmus_ucsc_all_cdna.idx \ - x verbinding < (pv all / 4T1_BC06 / 4T1_BC06.correctedReads.fasta.gz) | \ samtools sort > 4T1_BC06_all_vs_mmusAll.bam

Update: de meest recente nanopore basecaller, gecombineerd met de meest recente minimap2, lijkt nu een behoorlijk werk te doen met mapping, en pre-correctie van reads nee langer lijkt nodig. Meer recent heb ik LAST gebruikt om in kaart te brengen met het transcriptoom en minimap2 om in kaart te brengen met het genoom. Minimap2 heeft de mogelijkheid om een ​​met homopolymeer gecomprimeerde genoomindex te gebruiken, wat betekent dat de meest voorkomende consistente fout voor het uitlezen van nanoporiën (d.w.z. verkeerde inschatting van de homopolymeerlengte) de mappingsnelheid niet zal beïnvloeden.

Ja, ik heb uiteindelijk ook minimap2 gebruikt, bedankt. Op het moment van deze vraag probeerde ik gewoon te controleren of ik wat onzin deed met parameters voor STAR, of dat het gedrag gewoon te wijten was aan het algoritme. Bent u voor het corrigeren van leesopdrachten niet bang om de indel-samenstelling van uw leesopdrachten te wijzigen als u Canu gebruikt?
Nee ... waarom zou dat een probleem zijn? Canu corrigeert fouten op basis van de consensus van overlappende leesbewerkingen; Ik zie niet in waarom / hoe die correctie meer problemen zou veroorzaken dan oplost.


ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...