CIGAR-aware coverage
2
0
Entering edit mode
chris warth ▴ 30
@chris-warth-6295
Last seen 8.6 years ago
United States
I would like to gather coverage data for gapped alignments. I am using readGAlignmentsFromBam() to read a GAlignments object, converting to an IRanges object and calling IRanges::coverage() , but that ignores CIGAR strings. There appears to be a message to BIOC-devel on CIGAR-aware coverage ( https://www.mail-archive.com/bioc-devel at r-project.org/msg01460.html ) that suggests using the 'GenomicAlignments' package. As far as I can tell that is only available under 2.14, the development version of bioconductor, which would also require running R-devel. Is there any way to get CIGAR-aware coverage under bioconductor 2.13? Thanks in advance, Chris Warth Fred Hutchinson CRC P.S. Not to distract from the above question, but I would also like CIGAR-aware retrieval of alignments. readGAlignmentsFromBam() retrieves alignments whose gap completely spans the range I am interested in. I haven't found a way to exclude alignments that don't have any actual base alignments overlapping the range I asked for. ==== > sessionInfo() R version 3.0.2 (2013-09-25) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] C attached base packages: [1] parallel stats graphics grDevices utils datasets methods [8] base other attached packages: [1] wavelets_0.3-0 vegan_2.0-10 lattice_0.20-24 [4] permute_0.8-3 rtracklayer_1.21.14 Rsamtools_1.13.52 [7] Biostrings_2.29.19 BiocInstaller_1.12.0 GenomicRanges_1.14.4 [10] XVector_0.1.4 IRanges_1.20.6 BiocGenerics_0.7.8 loaded via a namespace (and not attached): [1] BSgenome_1.29.1 RCurl_1.95-4.1 XML_3.98-1.1 bitops_1.0-6 [5] compiler_3.0.2 grid_3.0.2 stats4_3.0.2 tools_3.0.2 [9] zlibbioc_1.7.0
Coverage IRanges Coverage IRanges • 1.8k views
ADD COMMENT •
0
Entering edit mode
@michael-lawrence-3846
Last seen 2.4 years ago
United States
On Thu, Feb 27, 2014 at 4:37 PM, chris warth <cswarth@gmail.com> wrote: > I would like to gather coverage data for gapped alignments. I am > using readGAlignmentsFromBam() to read a GAlignments object, > converting to an IRanges object and calling IRanges::coverage() , but > that ignores CIGAR strings. > There appears to be a message to BIOC-devel on CIGAR-aware coverage > ( https://www.mail-archive.com/bioc- devel@r-project.org/msg01460.html ) > that suggests using the 'GenomicAlignments' package. > > GenomicAlignments is mostly a reorganization of pre-existing functionality. You should be able to call coverage() directly on your GAlignments, or on the BamFile itself, with full support for cigar strings. Also, it is sufficient to call readGAlignments(), i.e., no need for "FromBam". > As far as I can tell that is only available under 2.14, the > development version of bioconductor, which would also require running > R-devel. > > Is there any way to get CIGAR-aware coverage under bioconductor 2.13? > > Thanks in advance, > > Chris Warth > Fred Hutchinson CRC > > P.S. Not to distract from the above question, but I would also like > CIGAR-aware retrieval of alignments. readGAlignmentsFromBam() > retrieves alignments whose gap completely spans the range I am > interested in. I haven't found a way to exclude alignments that > don't have any actual base alignments overlapping the range I asked > for. > > ==== > > sessionInfo() > R version 3.0.2 (2013-09-25) > Platform: x86_64-unknown-linux-gnu (64-bit) > > locale: > [1] C > > attached base packages: > [1] parallel stats graphics grDevices utils datasets methods > [8] base > > other attached packages: > [1] wavelets_0.3-0 vegan_2.0-10 lattice_0.20-24 > [4] permute_0.8-3 rtracklayer_1.21.14 Rsamtools_1.13.52 > [7] Biostrings_2.29.19 BiocInstaller_1.12.0 GenomicRanges_1.14.4 > [10] XVector_0.1.4 IRanges_1.20.6 BiocGenerics_0.7.8 > > loaded via a namespace (and not attached): > [1] BSgenome_1.29.1 RCurl_1.95-4.1 XML_3.98-1.1 bitops_1.0-6 > [5] compiler_3.0.2 grid_3.0.2 stats4_3.0.2 tools_3.0.2 > [9] zlibbioc_1.7.0 > > _______________________________________________ > Bioconductor mailing list > Bioconductor@r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor > [[alternative HTML version deleted]]
ADD COMMENT •
0
Entering edit mode
> GenomicAlignments is mostly a reorganization of pre-existing functionality. > You should be able to call coverage() directly on your GAlignments, or on > the BamFile itself, with full support for cigar strings. Also, it is > sufficient to call readGAlignments(), i.e., no need for "FromBam". > Thanks for this, I tried calling coverage() on GAlignments before and it wouldn't work for me, but looking closer I now understand the error. > class(myalignments) [1] "GAlignments" attr(,"package") [1] "GenomicRanges" > coverage(myalignments) Error in coverage(grglist(x, drop.D.ranges = drop.D.ranges), shift = shift, : error in evaluating the argument 'x' in selecting a method for function 'coverage': Error in validObject(.Object) : invalid class "GRangesList" object: 'mcols(x)' cannot have columns named "seqnames", "ranges", "strand", "start", "end", "width", or "element" Eliminating the metadata (what = c("pos", "qwidth", "strand")) in the alignments allows coverage() to work now. Why in the world does coverage() care if the alignments have strand metadata?
ADD REPLY •
0
Entering edit mode
Hi Chris, On 02/27/2014 11:00 PM, chris warth wrote: >> GenomicAlignments is mostly a reorganization of pre-existing functionality. >> You should be able to call coverage() directly on your GAlignments, or on >> the BamFile itself, with full support for cigar strings. Also, it is >> sufficient to call readGAlignments(), i.e., no need for "FromBam". >> > > Thanks for this, I tried calling coverage() on GAlignments before and > it wouldn't work for me, but looking closer I now understand the > error. > > > class(myalignments) > [1] "GAlignments" > attr(,"package") > [1] "GenomicRanges" > > > coverage(myalignments) > Error in coverage(grglist(x, drop.D.ranges = drop.D.ranges), shift = shift, : > error in evaluating the argument 'x' in selecting a method for > function 'coverage': Error in validObject(.Object) : > invalid class "GRangesList" object: 'mcols(x)' cannot have columns > named "seqnames", "ranges", "strand", "start", "end", "width", or > "element" > > > Eliminating the metadata (what = c("pos", "qwidth", "strand")) in the > alignments allows coverage() to work now. > > Why in the world does coverage() care if the alignments have strand metadata? It's not coverage() that cares. It's the internal coercion to GRangesList that happens internally before the coverage is actually computed. This internal coercion tries to propagate the metadata columns, but, for reasons I never really understood, GRanges and GRangesList objects are not allowed to hold a metadata column named "strand". The fix is easy: this internal coercion to GRangesList should not propagate the metadata columns (they're not needed for computing the coverage and they slow down the coercion). I'll fix this today. Thanks for the report. H. > > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor > -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319
ADD REPLY •
0
Entering edit mode
On Fri, Feb 28, 2014 at 9:47 AM, Hervé Pagès <hpages@fhcrc.org> wrote: > Hi Chris, > > > On 02/27/2014 11:00 PM, chris warth wrote: > >> GenomicAlignments is mostly a reorganization of pre-existing >>> functionality. >>> You should be able to call coverage() directly on your GAlignments, or on >>> the BamFile itself, with full support for cigar strings. Also, it is >>> sufficient to call readGAlignments(), i.e., no need for "FromBam". >>> >>> >> Thanks for this, I tried calling coverage() on GAlignments before and >> it wouldn't work for me, but looking closer I now understand the >> error. >> >> > class(myalignments) >> [1] "GAlignments" >> attr(,"package") >> [1] "GenomicRanges" >> >> > coverage(myalignments) >> Error in coverage(grglist(x, drop.D.ranges = drop.D.ranges), shift = >> shift, : >> error in evaluating the argument 'x' in selecting a method for >> function 'coverage': Error in validObject(.Object) : >> invalid class "GRangesList" object: 'mcols(x)' cannot have columns >> named "seqnames", "ranges", "strand", "start", "end", "width", or >> "element" >> >> >> Eliminating the metadata (what = c("pos", "qwidth", "strand")) in the >> alignments allows coverage() to work now. >> >> Why in the world does coverage() care if the alignments have strand >> metadata? >> > > It's not coverage() that cares. It's the internal coercion to > GRangesList that happens internally before the coverage is actually > computed. This internal coercion tries to propagate the metadata > columns, but, for reasons I never really understood, GRanges and > GRangesList objects are not allowed to hold a metadata column named > "strand". I think this is because there is otherwise ambiguity when coercing to a data.frame and also comes up now in the coercion of GRanges to an environment. We could just admit warnings in those cases though and rename with make.unique(). > The fix is easy: this internal coercion to GRangesList should > not propagate the metadata columns (they're not needed for computing the > coverage and they slow down the coercion). I'll fix this today. > > Thanks for the report. > H. > > > >> _______________________________________________ >> Bioconductor mailing list >> Bioconductor@r-project.org >> https://stat.ethz.ch/mailman/listinfo/bioconductor >> Search the archives: http://news.gmane.org/gmane. >> science.biology.informatics.conductor >> >> > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpages@fhcrc.org > Phone: (206) 667-5791 > Fax: (206) 667-1319 > [[alternative HTML version deleted]]
ADD REPLY •
0
Entering edit mode
On 02/28/2014 10:58 AM, Michael Lawrence wrote: > > > > On Fri, Feb 28, 2014 at 9:47 AM, Hervé Pagès <hpages at="" fhcrc.org=""> <mailto:hpages at="" fhcrc.org="">> wrote: > > Hi Chris, > > > On 02/27/2014 11:00 PM, chris warth wrote: > > GenomicAlignments is mostly a reorganization of pre- existing > functionality. > You should be able to call coverage() directly on your > GAlignments, or on > the BamFile itself, with full support for cigar strings. > Also, it is > sufficient to call readGAlignments(), i.e., no need for > "FromBam". > > > Thanks for this, I tried calling coverage() on GAlignments > before and > it wouldn't work for me, but looking closer I now understand the > error. > > > class(myalignments) > [1] "GAlignments" > attr(,"package") > [1] "GenomicRanges" > > > coverage(myalignments) > Error in coverage(grglist(x, drop.D.ranges = drop.D.ranges), > shift = shift, : > error in evaluating the argument 'x' in selecting a method for > function 'coverage': Error in validObject(.Object) : > invalid class "GRangesList" object: 'mcols(x)' cannot have > columns > named "seqnames", "ranges", "strand", "start", "end", "width", or > "element" > > > Eliminating the metadata (what = c("pos", "qwidth", "strand")) > in the > alignments allows coverage() to work now. > > Why in the world does coverage() care if the alignments have > strand metadata? > > > It's not coverage() that cares. It's the internal coercion to > GRangesList that happens internally before the coverage is actually > computed. This internal coercion tries to propagate the metadata > columns, but, for reasons I never really understood, GRanges and > GRangesList objects are not allowed to hold a metadata column named > "strand". > > > I think this is because there is otherwise ambiguity when coercing to a > data.frame and also comes up now in the coercion of GRanges to an > environment. We could just admit warnings in those cases though and > rename with make.unique(). A warning would be good. I'm not a big fan of automatic renaming though. Whatever we choose, we want as.data.frame() to handle the metadata cols consistently. Right now it doesn't: With a GAlignments: > gal GAlignments with 3 alignments and 2 metadata columns: seqnames strand cigar qwidth start end width <rle> <rle> <character> <integer> <integer> <integer> <integer> [1] seq1 + 36M 36 1 36 36 [2] seq1 + 35M 35 3 37 35 [3] seq1 + 35M 35 5 39 35 njunc | flag strand <integer> | <integer> <factor> [1] 0 | 73 + [2] 0 | 73 + [3] 0 | 137 + --- seqlengths: seq1 seq2 1575 1584 > as.data.frame(gal) seqnames strand cigar qwidth start end width njunc flag strand 1 seq1 + 36M 36 1 36 36 0 73 + 2 seq1 + 35M 35 3 37 35 0 73 + 3 seq1 + 35M 35 5 39 35 0 137 + With a GRanges (I artificially created an invalid object): > gr GRanges with 4 ranges and 1 metadata column: seqnames ranges strand | strand <rle> <iranges> <rle> | <character> [1] seq1 [1, 36] + | - [2] seq1 [3, 37] + | - [3] seq1 [5, 39] + | - [4] seq1 [6, 41] + | - --- seqlengths: seq1 seq2 1575 1584 > as.data.frame(gr) seqnames start end width strand strand.1 1 seq1 1 36 36 + - 2 seq1 3 37 35 + - 3 seq1 5 39 35 + - 4 seq1 6 41 36 + - H. > > The fix is easy: this internal coercion to GRangesList should > not propagate the metadata columns (they're not needed for computing the > coverage and they slow down the coercion). I'll fix this today. > > Thanks for the report. > H. > > > > _________________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org <mailto:bioconductor at="" r-project.org=""> > https://stat.ethz.ch/mailman/__listinfo/bioconductor > <https: stat.ethz.ch="" mailman="" listinfo="" bioconductor=""> > Search the archives: > http://news.gmane.org/gmane.__science.biology.informatics.__conductor > <http: news.gmane.org="" gmane.science.biology.informatics.conductor=""> > > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpages at fhcrc.org <mailto:hpages at="" fhcrc.org=""> > Phone: (206) 667-5791 <tel:%28206%29%20667-5791> > Fax: (206) 667-1319 <tel:%28206%29%20667-1319> > > -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319
ADD REPLY •
0
Entering edit mode
Hi Chris, On 02/27/2014 09:42 PM, Michael Lawrence wrote: > On Thu, Feb 27, 2014 at 4:37 PM, chris warth <cswarth at="" gmail.com=""> wrote: > >> I would like to gather coverage data for gapped alignments. I am >> using readGAlignmentsFromBam() to read a GAlignments object, >> converting to an IRanges object and calling IRanges::coverage() , but >> that ignores CIGAR strings. >> > > There appears to be a message to BIOC-devel on CIGAR-aware coverage >> ( https://www.mail-archive.com/bioc-devel at r-project.org/msg01460.html ) >> that suggests using the 'GenomicAlignments' package. >> >> > GenomicAlignments is mostly a reorganization of pre-existing functionality. > You should be able to call coverage() directly on your GAlignments, or on > the BamFile itself, with full support for cigar strings. Also, it is > sufficient to call readGAlignments(), i.e., no need for "FromBam". > > >> As far as I can tell that is only available under 2.14, the >> development version of bioconductor, which would also require running >> R-devel. >> >> Is there any way to get CIGAR-aware coverage under bioconductor 2.13? >> >> Thanks in advance, >> >> Chris Warth >> Fred Hutchinson CRC >> >> P.S. Not to distract from the above question, but I would also like >> CIGAR-aware retrieval of alignments. readGAlignmentsFromBam() >> retrieves alignments whose gap completely spans the range I am >> interested in. I haven't found a way to exclude alignments that >> don't have any actual base alignments overlapping the range I asked >> for. You cannot exclude alignments whose gap completely spans the range you specify in the 'which' arg of the ScanBamParam object you pass to readGAlignmentsFromBam(). However you can get rid of them right after readGAlignmentsFromBam() returns with something like: my_ROI <- GRanges("chr1, IRanges(1964, 2014)) # my region of interest gal <- readGAlignmentsFromBam(bamfile, ScanBamParam(which=my_ROI)) subsetByOverlaps(gal, my_ROI) This subsetting will only keep those alignments that have at least 1 aligned nucleotide that falls within 'my_ROI'. Cheers, H. >> >> ==== >>> sessionInfo() >> R version 3.0.2 (2013-09-25) >> Platform: x86_64-unknown-linux-gnu (64-bit) >> >> locale: >> [1] C >> >> attached base packages: >> [1] parallel stats graphics grDevices utils datasets methods >> [8] base >> >> other attached packages: >> [1] wavelets_0.3-0 vegan_2.0-10 lattice_0.20-24 >> [4] permute_0.8-3 rtracklayer_1.21.14 Rsamtools_1.13.52 >> [7] Biostrings_2.29.19 BiocInstaller_1.12.0 GenomicRanges_1.14.4 >> [10] XVector_0.1.4 IRanges_1.20.6 BiocGenerics_0.7.8 >> >> loaded via a namespace (and not attached): >> [1] BSgenome_1.29.1 RCurl_1.95-4.1 XML_3.98-1.1 bitops_1.0-6 >> [5] compiler_3.0.2 grid_3.0.2 stats4_3.0.2 tools_3.0.2 >> [9] zlibbioc_1.7.0 >> >> _______________________________________________ >> Bioconductor mailing list >> Bioconductor at r-project.org >> https://stat.ethz.ch/mailman/listinfo/bioconductor >> Search the archives: >> http://news.gmane.org/gmane.science.biology.informatics.conductor >> > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor > -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319
ADD REPLY •
0
Entering edit mode
On 02/27/2014 11:29 PM, Hervé Pagès wrote: > Hi Chris, > > On 02/27/2014 09:42 PM, Michael Lawrence wrote: >> On Thu, Feb 27, 2014 at 4:37 PM, chris warth <cswarth at="" gmail.com=""> wrote: >> >>> I would like to gather coverage data for gapped alignments. I am >>> using readGAlignmentsFromBam() to read a GAlignments object, >>> converting to an IRanges object and calling IRanges::coverage() , but >>> that ignores CIGAR strings. >>> >> >> There appears to be a message to BIOC-devel on CIGAR-aware coverage >>> ( https://www.mail-archive.com/bioc-devel at r-project.org/msg01460.html ) >>> that suggests using the 'GenomicAlignments' package. >>> >>> >> GenomicAlignments is mostly a reorganization of pre-existing >> functionality. >> You should be able to call coverage() directly on your GAlignments, or on >> the BamFile itself, with full support for cigar strings. Also, it is >> sufficient to call readGAlignments(), i.e., no need for "FromBam". >> >> >>> As far as I can tell that is only available under 2.14, the >>> development version of bioconductor, which would also require running >>> R-devel. >>> >>> Is there any way to get CIGAR-aware coverage under bioconductor 2.13? >>> >>> Thanks in advance, >>> >>> Chris Warth >>> Fred Hutchinson CRC >>> >>> P.S. Not to distract from the above question, but I would also like >>> CIGAR-aware retrieval of alignments. readGAlignmentsFromBam() >>> retrieves alignments whose gap completely spans the range I am >>> interested in. I haven't found a way to exclude alignments that >>> don't have any actual base alignments overlapping the range I asked >>> for. > > You cannot exclude alignments whose gap completely spans the range > you specify in the 'which' arg of the ScanBamParam object you pass > to readGAlignmentsFromBam(). However you can get rid of them right > after readGAlignmentsFromBam() returns with something like: > > my_ROI <- GRanges("chr1, IRanges(1964, 2014)) # my region of interest > gal <- readGAlignmentsFromBam(bamfile, ScanBamParam(which=my_ROI)) > subsetByOverlaps(gal, my_ROI) Trying this again: my_ROI <- GRanges("chr1", IRanges(1964, 2014)) # my region of interest gal <- readGAlignmentsFromBam(bamfile, param=ScanBamParam(which=my_ROI)) subsetByOverlaps(gal, my_ROI) Hope that works for you. H. > > This subsetting will only keep those alignments that have at least 1 > aligned nucleotide that falls within 'my_ROI'. > > Cheers, > H. > >>> >>> ==== >>>> sessionInfo() >>> R version 3.0.2 (2013-09-25) >>> Platform: x86_64-unknown-linux-gnu (64-bit) >>> >>> locale: >>> [1] C >>> >>> attached base packages: >>> [1] parallel stats graphics grDevices utils datasets methods >>> [8] base >>> >>> other attached packages: >>> [1] wavelets_0.3-0 vegan_2.0-10 lattice_0.20-24 >>> [4] permute_0.8-3 rtracklayer_1.21.14 Rsamtools_1.13.52 >>> [7] Biostrings_2.29.19 BiocInstaller_1.12.0 GenomicRanges_1.14.4 >>> [10] XVector_0.1.4 IRanges_1.20.6 BiocGenerics_0.7.8 >>> >>> loaded via a namespace (and not attached): >>> [1] BSgenome_1.29.1 RCurl_1.95-4.1 XML_3.98-1.1 bitops_1.0-6 >>> [5] compiler_3.0.2 grid_3.0.2 stats4_3.0.2 tools_3.0.2 >>> [9] zlibbioc_1.7.0 >>> >>> _______________________________________________ >>> Bioconductor mailing list >>> Bioconductor at r-project.org >>> https://stat.ethz.ch/mailman/listinfo/bioconductor >>> Search the archives: >>> http://news.gmane.org/gmane.science.biology.informatics.conductor >>> >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> Bioconductor mailing list >> Bioconductor at r-project.org >> https://stat.ethz.ch/mailman/listinfo/bioconductor >> Search the archives: >> http://news.gmane.org/gmane.science.biology.informatics.conductor >> > -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319
ADD REPLY •
0
Entering edit mode
@michael-lawrence-3846
Last seen 2.4 years ago
United States
The strand metadata constraint is introduced by the intermediate GRangesList representation on which coverage is actually calculated. Perhaps we should be consistent and disallow the use of fixed column names in the metadata of GAlignments, as well. I'm kind of surprised that readGAlignments does not just drop the request for what="strand", since it includes it as a fixed column anyway. On Thu, Feb 27, 2014 at 11:00 PM, chris warth <cswarth@gmail.com> wrote: > > GenomicAlignments is mostly a reorganization of pre-existing > functionality. > > You should be able to call coverage() directly on your GAlignments, or on > > the BamFile itself, with full support for cigar strings. Also, it is > > sufficient to call readGAlignments(), i.e., no need for "FromBam". > > > > Thanks for this, I tried calling coverage() on GAlignments before and > it wouldn't work for me, but looking closer I now understand the > error. > > > class(myalignments) > [1] "GAlignments" > attr(,"package") > [1] "GenomicRanges" > > > coverage(myalignments) > Error in coverage(grglist(x, drop.D.ranges = drop.D.ranges), shift = > shift, : > error in evaluating the argument 'x' in selecting a method for > function 'coverage': Error in validObject(.Object) : > invalid class "GRangesList" object: 'mcols(x)' cannot have columns > named "seqnames", "ranges", "strand", "start", "end", "width", or > "element" > > > Eliminating the metadata (what = c("pos", "qwidth", "strand")) in the > alignments allows coverage() to work now. > > Why in the world does coverage() care if the alignments have strand > metadata? > [[alternative HTML version deleted]]
ADD COMMENT •

Login before adding your answer.

Similar Posts
Loading Similar Posts
Traffic: 1057 users visited in the last hour
Content Search
Users
Tags
Badges
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6