Kysymys:
Kuinka voin tunnistaa järjestelmällisesti tuntemattomat viivakoodi- / sovitinsekvenssit näytesarjassa?
story
2017-05-31 14:49:30 UTC
view on stackexchange narkive permalink

Olen usein ladannut tietoaineistoja SRA: lta, jossa kirjoittajat eivät maininneet, mitkä adapterit on leikattu käsittelyn aikana.

Paikalliset linjaukset pyrkivät voittamaan tämän esteen, mutta se tuntuu hieman barbaariselta.

fastQC pyrkii toisinaan hakemaan ne, mutta joskus ei löydä todellisia sovitinsekvenssejä.

Yleensä päädyin etsimään heidän käyttämänsä sarjat ja yrittämään tarttua kaikkiin mahdollisiin viivakoodeihin.

Onko tähän vankempi / tehokkaampi tapa?

Tämä ei vastaa kysymykseesi, mutta toivon, että on mahdollista ilmoittaa tällaisista ongelmista SRA: lle, jotta he pyytävät kirjoittajia julkaisemaan puuttuvat tiedot.
Miksi sinusta tuntuu, että paikallinen linjaus on hieman barbaarista? Sen pitäisi olla oletusmenetelmä tänä päivänä ja iässä, ellet työskentele smallRNA-sekvensoinnin kanssa. Minulla on taipumus leikata sovittimia turvallisella puolella, mutta tein paljon työtä häiritsemättä ja vain luottaen paikalliseen linjaukseen.
Neljä vastused:
ewels
2017-06-02 12:52:08 UTC
view on stackexchange narkive permalink

Mainitset, että FastQC "ei löydä todellisia sovitinsekvenssejä" - luulen tarkoittavan sitä sovittimen sekvenssikontaminaatiokaaviossa. Kmer- ja sekvenssisisältö ovat kuitenkin usein hyödyllisiä myös silloin, kun edellinen epäonnistuu. Olen käyttänyt näitä aiemmin - voit joskus vain lukea sovitinsarjan sekvenssisuunnittelun alusta (tai ainakin nähdä, kuinka monta emästä leikata).

gringer
2017-05-31 15:45:23 UTC
view on stackexchange narkive permalink

En ole tietoinen olemassa olevista menetelmistä tämän tekemiseen, mutta tässä on muutama idea siitä, miten se voidaan tehdä:

Canu käyttää sovittimen trimmausmenetelmää, joka tarkoittaa poissaolon etsimistä lukujen päällekkäisyyttä. Jos ei ole muita lukuja, jotka jakavat sekvenssin tietyllä alueella, luku hajotetaan matalalla peittoalueella ja pienet palat heitetään pois. Tällaisen menetelmän avulla olisi mahdollista etsiä mahdollisia adapteri- / viivakoodisekvenssejä säilyttämällä lyhyet lukut.

Toinen vaihtoehto on tehdä kmer-haku lukemisen alussa ja nähdä, onko jokin suuria määriä kilometrejä voidaan koota yhteen ja / tai sovittaa olemassa olevien tunnettujen sovittimien tai viivakoodien kanssa.

bli
2017-05-31 15:28:26 UTC
view on stackexchange narkive permalink

Jos satut tuntemaan jakson, jonka pitäisi olla runsaasti kirjastossa, voit napata sen alun tai lopun (kuvion vastaavuuden korostuksella) ja katsoa, ​​tuleeko sama sekvenssi järjestelmällisesti juuri ennen vastaavaa vai vasta sen jälkeen. Tällainen visuaalinen tarkastus voi auttaa sinua löytämään sovittimen.

Esimerkiksi edellisessä laboratoriossa työskentelimme D. melanogaster pienet RNA-sekvensointitiedot ja kollegani tiesivät aikaisemmasta kokemuksesta tällaisilla tiedoilla, että seuraavan pienen RNA: n todennäköisesti oli runsaasti: http://flybase.org/reports/FBgn0065042.html

Meidän piti vain napata se fastq-tiedostossa nähdäksemme monia rivejä tällä sekvenssillä toisen sekvenssin vieressä, joka sattui olemaan aina sama: tuntematon sovitin.

Voinko tietää alemman äänen syyn? Olen nähnyt tämän menetelmän sovelletun pienen RNA-sekvenssin tapauksessa, jossa odotettiin yhtä erittäin runsasta sekvenssiä. Tämän sekvenssin grep-ulostulon visuaalinen tarkastelu (kuvion korostuksella) antoi erittäin hyvän vihjeen siitä, mikä sovitin oli (korostamaton osa).
Kysymys koskee tuntemattomien sovitinsekvenssien havaitsemista, joten OP ei tiedä runsaista sekvensseistä etukäteen. Se on eräänlainen kysymyksen asia ...
@tallphil En näe yhteyttä sovittimen tuntemattomuuden ja datassa odotettavissa olevan runsaan sekvenssin välillä. Jos muistan hyvin, esimerkissä, jonka mainitsin kommentissani, kollegani tiesi aikaisemmasta kokemuksesta tällaisilla tiedoilla, että seuraava pieni RNA oli todennäköisesti runsas: http://flybase.org/reports/FBgn0065042.htmlWe just piti tarttua siihen fastq-tiedostoon nähdäksesi useita rivejä tällä sekvenssillä toisen sekvenssin vieressä, joka sattui olemaan aina sama: tuntematon sovitin.
Itse luin vain uudestaan ​​viestisi ja nyt näen mitä tarkoitit. Tämä on järkevä idea. Luulen kuitenkin, että selitit sen huonosti siinä mielessä, että lukija saattaa olla hämmentynyt ja luulit tarkoittanesi, että kaikkein runsaimman jakson etsiminen saattaisi johtaa viivakoodiin. Sinun olisi pitänyt täsmentää, että "runsas sekvenssi" oli tässä tapauksessa tunnettu nukleiinihapposekvenssi, jonka oletetaan olevan liitettyjä adaptereja yhteen tai molempiin päihin.
Ah kyllä, anteeksipyynnöt - juuri näin luin sen. Luultavasti ei auttanut sitä, että alkuperäisessä kysymyksessä mainittiin odotettujen sovitinsekvenssien hakeminen, joten tämä oli mielessäni uutta :) Anteeksi @bli! Downvote ei ollut minulta, joten en voi peruuttaa sitä, pelkään.
Yritin selventää selityksiäni.
Nils
2017-06-02 16:41:16 UTC
view on stackexchange narkive permalink

Kraken / reaper -työkalupaketin minion -apuohjelma voi olla hyödyllinen tässä: http://wwwdev.ebi.ac.uk/enright-dev/kraken/reaper/src/ reaper-latest / doc / minion.html

Tämä näyttää täsmälleen oikean tyyppiseltä työkalulta. Vaikka se oli liian huono, se on suunniteltu pääasiassa 3 '-pääsovitinta varten. Ihmettelen, voisitko vain kääntää kaikki lukemasi ja soveltaa sitä 5'-päähän.


ⓘ
Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...