copyCountSegments(fit) failed exomeCopy
1
0
Entering edit mode
@dan-spiegelman-5248
Last seen 10.2 years ago
[key lines from earlier threads:] love <love at="" ...=""> writes: > This appears to be a bug for fitted objects which have no predicted > variants (as the show command gives "percent normal state: 100%"). I will > fix it. > > From: John linux-user <johnlinuxuser <at=""> yahoo.com> > > Sent: Sunday, March 18, 2012 1:54 PM > >> fit <- exomeCopy(exomecounts["chr1"],sample.name="HGPIPE_6159", > > +??????????????????? X.names=c("bg","GC","GC.sq","width"),S=0:6,d=2) > >>?? show(fit) > > > > ExomeCopy object > > type: exomeCopy > > percent normal state: 100% > >> copyCountSegments(fit) > > Error in .Call2("solve_user_SEW0", start, end, width, PACKAGE = > "IRanges") > > : > > ? solving row 1: negative widths are not allowed Hello, I am encountering a similar problem, though my data DOES have variants (i.e. is not 100% normal state). In setting up this analysis, I followed the procedure laid out in http://www.bioconductor.org/packages/2.9/bioc/vignettes/exomeCopy/inst /doc/exome Copy.pdf virtually to the letter (except where my sample names and bamfile paths are concerned). here the key lines of R code and output: > fit <- exomeCopy(rdata["22"],sample.name="S12993",X.names=c("bg","GC","GC.sq" ,"width"), S=0:6,d=2) > show(fit) > copyCountSegments(fit) Error in .Call2("solve_user_SEW0", start, end, width, PACKAGE = "IRanges") : solving row 113: negative widths are not allowed here is the problematic line of my object, with 1 flanking row on both sides: > rdata["22"][112:114,] RangedData with 3 rows and 7 value columns across 1 space space ranges | bg GC GC.sq width <factor> <iranges> | <numeric> <numeric> <numeric> <integer> 1 22 [17265302, 17265408] | 0.05448944 0.2803738 0.07860949 107 2 22 [17265409, 17265516] | 0.00000000 0.2685185 0.07210219 108 3 22 [17264572, 17264679] | 0.05448944 0.3981481 0.15852195 108 S12993 S13514 S13045 <integer> <integer> <integer> 1 0 8 2 2 0 1 0 3 0 31 2 as you can see above, the width in question is clearly not negative (value=108). I chose to show chr22 as an example, but in fact this problem appears in any other contig I use. Another strange issue is that my output for the show(fit) command is not simply the 3 lines I expected, but also includes the entire object (or as many lines as can be output to screen) plus a list of what look like debugging details (various variables with their associated values). This may or may not be germane to the problem. I am relatively new to R, and certainly have never used the IRanges package before. Maybe I'm missing something essential here (very likely). For reference purposes, here is a sample of the strange show(fit) output: > show(fit) ... [75841] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 [75846] 0.000000e+00 0.000000e+00 0.000000e+00 9.017138e+00 3.646900e+00 [75851] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 [75856] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 [75861] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 [75866] 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 [75871] 0.000000e+00 0.000000e+00 0.000000e+00 5.866668e+00 3.430158e+00 [75876] 4.921296e-01 4.921296e-01 4.921296e-01 4.921296e-01 4.921296e-01 ... Slot "fx.par": $S [1] 0 1 2 3 4 5 6 $d [1] 2 $normal.state [1] 3 $fit.var [1] FALSE Slot "init.par": $goto.cnv [1] 1e-04 $goto.normal [1] 0.05 $beta.hat intercept bg GC GC.sq width 30.5079982 60.4831813 -9.5804591 8.0219697 0.3726371 $phi.hat [1] 0.1323678 Slot "final.par": $goto.cnv 0.008851164 $goto.normal 0.2046247 $beta intercept bg GC GC.sq width 29.4767639 58.9864999 -2.0047419 1.7713904 0.1083148 $gamma NULL $phi [1] 0.02133286 Slot "counts": function gradient 307 NA Slot "convergence": [1] 0 Slot "nll": [1] 184461.1 finally, here are my session details: > sessionInfo() R version 2.15.0 (2012-03-30) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] exomeCopy_1.2.0 Rsamtools_1.8.4 Biostrings_2.24.1 [4] GenomicRanges_1.8.3 IRanges_1.14.2 BiocGenerics_0.2.0 loaded via a namespace (and not attached): [1] bitops_1.0-4.1 stats4_2.15.0 zlibbioc_1.2.0 Thank you for any help you can provide Dan
exomeCopy exomeCopy • 1.4k views
ADD COMMENT
0
Entering edit mode
love ▴ 150
@love-5173
Last seen 10.2 years ago
hello Dan, The issue appears to be some unsorted ranges in rdata, which are probably coming from overlapping regions in the target BED file from Agilent. A solution is to first sort and reduce the original GRanges object 'target': target <- reduce(sort(target)) I should make subdivideGRanges do this automatically and I should check in the downstream functions that the ranges are in fact in order. > as.data.frame(ranges(rdata["22"]))[4256:4259,] space start end width 4256 22 19951678 19951784 107 4257 22 19951785 19951891 107 4258 22 19951046 19951148 103 4259 22 19951149 19951252 104 best, Mike Message: 35 Date: Mon, 23 Apr 2012 19:45:32 +0000 From: Dan Spiegelman <dan.spiegelman at="" crchum.qc.ca=""> To: <bioconductor at="" stat.math.ethz.ch=""> Subject: Re: [BioC] copyCountSegments(fit) failed exomeCopy Message-ID: <loom.20120423t214423-761 at="" post.gmane.org=""> Content-Type: text/plain; charset="utf-8" Hello, I am encountering a similar problem, though my data DOES have variants (i.e. is not 100% normal state). In setting up this analysis, I followed the procedure laid out in http://www.bioconductor.org/packages/2.9/bioc/vignettes/exomeCopy/ inst/doc/exome Copy.pdf virtually to the letter (except where my sample names and bamfile paths are concerned).
ADD COMMENT

Login before adding your answer.

Traffic: 541 users visited in the last hour
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