{"action":"created","issue":{"url":"https://api.github.com/repos/gpertea/stringtie/issues/19","labels_url":"https://api.github.com/repos/gpertea/stringtie/issues/19/labels{/name}","comments_url":"https://api.github.com/repos/gpertea/stringtie/issues/19/comments","events_url":"https://api.github.com/repos/gpertea/stringtie/issues/19/events","html_url":"https://github.com/gpertea/stringtie/issues/19","id":100526627,"number":19,"title":"Exons not being trimmed in ssRNAseq data, combining adjacent genes","user":{"login":"fletchdkfz","id":10436450,"avatar_url":"https://avatars.githubusercontent.com/u/10436450?v=3","gravatar_id":"","url":"https://api.github.com/users/fletchdkfz","html_url":"https://github.com/fletchdkfz","followers_url":"https://api.github.com/users/fletchdkfz/followers","following_url":"https://api.github.com/users/fletchdkfz/following{/other_user}","gists_url":"https://api.github.com/users/fletchdkfz/gists{/gist_id}","starred_url":"https://api.github.com/users/fletchdkfz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fletchdkfz/subscriptions","organizations_url":"https://api.github.com/users/fletchdkfz/orgs","repos_url":"https://api.github.com/users/fletchdkfz/repos","events_url":"https://api.github.com/users/fletchdkfz/events{/privacy}","received_events_url":"https://api.github.com/users/fletchdkfz/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-08-12T11:59:53Z","updated_at":"2015-08-21T17:58:50Z","closed_at":null,"body":"Hello,\r\n\r\nI've been playing with StringTie for the past few months and I've come to believe that - with the strand-specific RNAseq data that I have, at least - the trimming of exons at drops in coverage is not occurring.\r\n\r\nI observe this behaviour for both the first/last exon/UTRs and also internal exons; the example I've attached below shows the gene on the right having very good coverage over the last exon/UTR and a dropoff in coverage where the RefSeq reference transcript ends; however, StringTie additionally assembles the reads between the two genes into one long exon, and so ends up stitching together two transcripts into one artefactual one.\r\n\r\n![20150812_igv_02_no_trimming](https://cloud.githubusercontent.com/assets/10436450/9223398/159a29c8-40fa-11e5-988d-c7e7e77fb06c.png)\r\n\r\nThis particular assembly was run with minimum isoform fraction of 0.2 - if I lower this to 0.1 or 0.05 there are many, many more untrimmed exons (presumably because they are not filtered out because they pass this minimum isoform threshold).\r\n\r\nCheers!"},"comment":{"url":"https://api.github.com/repos/gpertea/stringtie/issues/comments/133513223","html_url":"https://github.com/gpertea/stringtie/issues/19#issuecomment-133513223","issue_url":"https://api.github.com/repos/gpertea/stringtie/issues/19","id":133513223,"user":{"login":"ohdongha","id":748486,"avatar_url":"https://avatars.githubusercontent.com/u/748486?v=3","gravatar_id":"","url":"https://api.github.com/users/ohdongha","html_url":"https://github.com/ohdongha","followers_url":"https://api.github.com/users/ohdongha/followers","following_url":"https://api.github.com/users/ohdongha/following{/other_user}","gists_url":"https://api.github.com/users/ohdongha/gists{/gist_id}","starred_url":"https://api.github.com/users/ohdongha/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ohdongha/subscriptions","organizations_url":"https://api.github.com/users/ohdongha/orgs","repos_url":"https://api.github.com/users/ohdongha/repos","events_url":"https://api.github.com/users/ohdongha/events{/privacy}","received_events_url":"https://api.github.com/users/ohdongha/received_events","type":"User","site_admin":false},"created_at":"2015-08-21T17:58:50Z","updated_at":"2015-08-21T17:58:50Z","body":"Dear Dr Pertea,\r\nThanks for the response!\r\n  \r\nIn my example, I supplied Stringtie with ORF models called by an <i>ab initio</i> gene predictor, as a reference annotation (in the IGV screenshot, they are Tp1g09210, 09220, and 09230).  Stringtie seemed to create a copy of each supplied ORF model by default (in the screenshot, TCONS_00001301, 1302, and 5621).  These copies of annotated ORFs (all having class_id \"=\"), being ORFs rather than full transcripts, correctly had mostly 0 FPKMs, if there alternative transcripts assembled with proper TSS and TES.  Hence, in the example I attached above, all newly assembled transcripts (TCONS_0001299 and 1300) were chimeras of what appeared as three separate genes, and were with high FPKMs.  This was commonplace when genes were closely spaced.\r\n\r\nI really like the \"trimming\" functionality, which appears to estimate TSS and TES positions as best as possible from the RNA-seq coverage.  I wonder whether there is a way to control the sensitivity of this trimming.  How the Stringtie detects the drop of RNA-seq coverage?  \r\n\r\nI would like to also know which parameter should be changed, to exclude from the assembly those low coverage reads that extend over the range of a gene.  If I could set a minimum threshold for something like Kmer occurrence, or read coverage (either absolute value, or, maybe better, compared to adjacent genomic regions), I think some of those assemblies overflowing into a neighboring gene could be prevented.  So far I tried to increase -c options, but it didn't improve the situation.  (Maybe I should try running Jellyfish and exclude low coverage reads before starting Stringtie...?)\r\n\r\nAny advice/suggestion would be appreciated.  Thanks again! \r\n\r\nBest wishes,\r\nDong-Ha "}}