Re: [aroma.affymetrix] Problem with read CDF files
Hi Wero, Dario is right, as explained in http://aroma-project.org/node/66. Also, I would recommend not to manually add data in the installation directories of R packages. When you upgrade to a new version of R, your data will still be stuck in the installation directory of the old version. Specificially, I would avoid (1) having your 'annotationData' (and all the others aroma.* folders) in the directory where aroma.affymetrix is installed, and (2) using this installation directory as you working directory. See http://aroma-project.org/node/79 for an example of setup. Also, remember that 'annotationData' in the working directory can be a symbolic link to another directory on your file system. Hope this helps, Pierre On Mon, Sep 27, 2010 at 5:05 PM, Dario Strbenac d.strbe...@garvan.org.au wrote: Hello, You need to be in the directory above annotationData. - Dario. Original message Date: Mon, 27 Sep 2010 16:53:06 -0700 (PDT) From: aroma-affymetrix@googlegroups.com (on behalf of Wero ivansk...@gmail.com) Subject: [aroma.affymetrix] Problem with read CDF files To: aroma.affymetrix aroma-affymetrix@googlegroups.com Cc: ii...@inmegen.gob.mx Hi, I have been trying to read the CDF files for the HuGene-1_0-st-v1 array with aroma.affymetrix and it has been very confuse for me. I have the correct CDF files from the aroma page. The CDF files are in the path: /Library/Frameworks/R.framework/ Versions/2.11/Resources/library/aroma.affymetrix/annotationData/ chipTypes/HuGene-1_0-st-v1. My working directory is: annotationData but I still have this error: # cdf - AffymetrixCdfFile$byChipType(chipType, tags=r3) Error in list(`AffymetrixCdfFile$byChipType(chipType, tags = r3)` = environment, : [2010-09-27 06:14:53] Exception: Could not locate a file for this chip type: HuGene-1_0-st-v1,r3 at throw(Exception(...)) at throw.default(Could not locate a file for this chip type: , pa at throw(Could not locate a file for this chip type: , paste(c(ch at method(static, ...) at AffymetrixCdfFile$byChipType(chipType, tags = r3) ## Also, if I look for the cdf path file in R, it returns NULL pathname - annotationData/chipTypes/HuGene-1_0-st-v1/HuGene-1_0-st-v1,r3.cdf cdf - AffymetrixCdfFile(pathname) Error in list(`AffymetrixCdfFile(pathname)` = environment, `extend(AromaChipTypeAnnotationFile(...), c(AffymetrixCdfFile, ` = environment, : [2010-09-27 06:48:54] Exception: Pathname not found: annotationData/ chipTypes/HuGene-1_0-st-v1/HuGene-1_0-st-v1,r3.cdf (none of the parent directories [annotationData/chipTypes/HuGene-1_0-st-v1/] exist; current directory is '/Library/Frameworks/R.framework/Versions/2.11/ Resources/library/aroma.affymetrix/annotationData/chipTypes/HuGene-1_0- st-v1') at throw(Exception(...)) at throw.default(Pathname not found: , pathname, reason) at throw(Pathname not found: , pathname, reason) at method(static, ...) at Arguments$getReadablePathname(filename, path = path, mustExist = at GenericDataFile(...) at extend(GenericDataFile(...), AromaMicroarrayDataFile) at AromaMicroarrayDataFile(...) at extend(AromaMicroarrayDataFile(...), c(AffymetrixFile, uses(A at AffymetrixFile(...) at extend(AffymetrixFile(...), AromaChipTypeAnnotationFile) at AromaChipTypeAnnotationFile(...) at extend(AromaChipTypeAnnotationFile(...), c(AffymetrixCdfFile, at Affymetrix In addition: Warning messages: 1: In is.na(parent) : is.na() applied to non-(list or vector) of type 'NULL' 2: In is.na(parent) : is.na() applied to non-(list or vector) of type 'NULL' pathname - getPathname(cdf) print(pathname) [1] annotationData/chipTypes/HuGene-1_0-st-v1/HuGene-1_0-st- v1,r3.cdf pathname2 - AffymetrixCdfFile$findByChipType(HuGene-1_0-st-v1, tags=3) print(pathname2) NULL ### This is my sessionInfo() R version 2.11.1 (2010-05-31) i386-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods [7] base other attached packages: [1] oligoClasses_1.10.0 Biobase_2.8.0 [3] aroma.affymetrix_1.7.0 aroma.apd_0.1.7 [5] affxparser_1.20.0 R.huge_0.2.0 [7] aroma.core_1.7.0 aroma.light_1.16.1 [9] matrixStats_0.2.1 R.rsp_0.4.0 [11] R.cache_0.3.0 R.filesets_0.9.0 [13] digest_0.4.2 R.utils_1.5.2 [15] R.oo_1.7.4 oligo_1.12.2 [17] R.methodsS3_1.2.1 loaded via a namespace (and not attached): [1] affyio_1.16.0 Biostrings_2.16.5 DBI_0.2-5 [4] IRanges_1.6.6 preprocessCore_1.10.0 splines_2.11.1 [7] tools_2.11.1 This is my traceback() 6: throw.Exception(Exception(...)) 5: throw(Exception(...)) 4: throw.default(msg) 3: throw(msg) 2: method(static, ...) 1: AffymetrixCdfFile$fromChipType(HuGene-1_0-st-v1, tags = r3) ### I would appreciate any help, thanks!!! Wero.
Re: [aroma.affymetrix] unusual copy number analysis result - split copy numbers
Hi. On Tue, Sep 28, 2010 at 11:54 AM, Patrick Danaher patrickjdana...@gmail.com wrote: Hi Henrik, Thanks for your response. The thread you suggested ( http://goo.gl/FGVe ) describes my problem well - I'm getting a very similar intensity profile for some chromosomes in some samples. The attached png shows the problem (red dots are intensities; the black dots are from a copy number calling problem and can be ignored). The second figure plots the called intensities against normal reference intensities for the same loci. As for your specific questions: I've never used CRMAv2 before, my dataset isn't public, and it's an affy 6.0 chip. What's your chip type? The other thread reported problems on Mapping250K_Sty though labelled as Sty 2 and I don't know what the 2 means there. Do you think annotation issues would cause this problem only in a small subset of my samples? When I say annotation issues, I really mean that if the CDF for the chip type is not the correct one, you might pick up the wrong probe signals, especially for SNPs, e.g. PM_A may get the value of a total CN probe once in a while, say. It could be a software/annotation bug in the Affymetrix DAT to CEL file conversion and so on. That's why it is crucial to know more about the chip used. I also recommend that you try dChip and/or Affymetrix GTC, if possible. /Henrik Thanks, Patrick On Sun, Sep 26, 2010 at 1:36 PM, Henrik Bengtsson h...@aroma-project.org wrote: Hi. On Mon, Sep 13, 2010 at 4:19 PM, Patrick patrickjdana...@gmail.com wrote: Hi everyone, I'm using AROMA's implementation of the CRMA v2 method to get copy number estimates for cancer samples, and I'm getting a very unusual result. Many of the samples have a chromosome where AROMA has called primarily copy number gains or losses, and the losses are mixed in with each other. That is, if you plot the probes' intensities by their positions on the chromosome, you see large stretches (~10,000 probes) where there are no intensities in the normal range (corresponding to no gain or loss), and there are intensities both above and below the normal range, mixed in with each other along the chromosome. It is as if the plots for a chromosome with a long deletion and a chromosome with a long addition were laid atop each other. It is not 100% clear from your description what you are observing. Note that it is possible to attach PNGs to messages sent to this mailing list as long as you send it as an email (not via the web interface). What chip type are you working on and do you look at a public data set? Have you used CRMAv2 on other data sets without a problem? FYI, Johan Staaf reported odd looking copy number results that are reproducible and very odd. See thread 'Problems with Affymetrix 250K Sty2 arrays after CRMAv2 analysis' on June 23-August 5, 2010, cf. http://goo.gl/FGVe. From the discussion in that thread, it seems to have something to do with annotation issues, but it is still to be solved. Is that what you are experiencing? It seems implausible that a cancer sample would have copy number gains and losses mixed in with each other in such small intervals, over such large stretches of chromosome, without any loci having the usual 2 copies, so I suspect the normalization or the affy array is the source of this phenomenon. I looked at the data without using AROMA, and the phenomenon was not evident. I re-normalized the data 3 times, each time using only one step of the AROMA normalization in isolation. The base position normalization step produced the phenomenon, and the allele crosstalk calibration and the fragment length normalization steps did not. What would help troubleshooting is if you could see other software such as dChip of Affymetrix GTC produces the same oddities. If they do, we know for sure it's something odd with the annotation. /Henrik Any thoughts on what I'm seeing and on how the base pair normalization could cause it would be very appreciated. Thanks, Patrick -- When reporting problems on aroma.affymetrix, make sure 1) to run the latest version of the package, 2) to report the output of sessionInfo() and traceback(), and 3) to post a complete code example. You received this message because you are subscribed to the Google Groups aroma.affymetrix group with website http://www.aroma-project.org/. To post to this group, send email to aroma-affymetrix@googlegroups.com To unsubscribe and other options, go to http://www.aroma-project.org/forum/ -- When reporting problems on aroma.affymetrix, make sure 1) to run the latest version of the package, 2) to report the output of sessionInfo() and traceback(), and 3) to post a complete code example. You received this message because you are subscribed to the Google Groups aroma.affymetrix group with website http://www.aroma-project.org/. To post to this group, send email to
Re: [aroma.affymetrix] unusual copy number analysis result - split copy numbers
On Tue, Sep 28, 2010 at 12:03 PM, hb h...@biostat.ucsf.edu wrote: Hi. On Tue, Sep 28, 2010 at 11:54 AM, Patrick Danaher patrickjdana...@gmail.com wrote: Hi Henrik, Thanks for your response. The thread you suggested ( http://goo.gl/FGVe ) describes my problem well - I'm getting a very similar intensity profile for some chromosomes in some samples. The attached png shows the problem (red dots are intensities; the black dots are from a copy number calling problem and can be ignored). The second figure plots the called intensities against normal reference intensities for the same loci. As for your specific questions: I've never used CRMAv2 before, my dataset isn't public, and it's an affy 6.0 chip. What's your chip type? The other thread reported problems on Mapping250K_Sty though labelled as Sty 2 and I don't know what the 2 means there. Woops, I read it as it was *not* a GenomeWideSNP_6 chip in your ...and it's an affy 6.0 chip note. So, it is GenomeWideSNP_6. Do you think annotation issues would cause this problem only in a small subset of my samples? When I say annotation issues, I really mean that if the CDF for the chip type is not the correct one, you might pick up the wrong probe signals, especially for SNPs, e.g. PM_A may get the value of a total CN probe once in a while, say. It could be a software/annotation bug in the Affymetrix DAT to CEL file conversion and so on. That's why it is crucial to know more about the chip used. I also recommend that you try dChip and/or Affymetrix GTC, if possible. Since it is GenomeWideSNP_6, you should be able to try it on Affymetrix GTC. /Henrik /Henrik Thanks, Patrick On Sun, Sep 26, 2010 at 1:36 PM, Henrik Bengtsson h...@aroma-project.org wrote: Hi. On Mon, Sep 13, 2010 at 4:19 PM, Patrick patrickjdana...@gmail.com wrote: Hi everyone, I'm using AROMA's implementation of the CRMA v2 method to get copy number estimates for cancer samples, and I'm getting a very unusual result. Many of the samples have a chromosome where AROMA has called primarily copy number gains or losses, and the losses are mixed in with each other. That is, if you plot the probes' intensities by their positions on the chromosome, you see large stretches (~10,000 probes) where there are no intensities in the normal range (corresponding to no gain or loss), and there are intensities both above and below the normal range, mixed in with each other along the chromosome. It is as if the plots for a chromosome with a long deletion and a chromosome with a long addition were laid atop each other. It is not 100% clear from your description what you are observing. Note that it is possible to attach PNGs to messages sent to this mailing list as long as you send it as an email (not via the web interface). What chip type are you working on and do you look at a public data set? Have you used CRMAv2 on other data sets without a problem? FYI, Johan Staaf reported odd looking copy number results that are reproducible and very odd. See thread 'Problems with Affymetrix 250K Sty2 arrays after CRMAv2 analysis' on June 23-August 5, 2010, cf. http://goo.gl/FGVe. From the discussion in that thread, it seems to have something to do with annotation issues, but it is still to be solved. Is that what you are experiencing? It seems implausible that a cancer sample would have copy number gains and losses mixed in with each other in such small intervals, over such large stretches of chromosome, without any loci having the usual 2 copies, so I suspect the normalization or the affy array is the source of this phenomenon. I looked at the data without using AROMA, and the phenomenon was not evident. I re-normalized the data 3 times, each time using only one step of the AROMA normalization in isolation. The base position normalization step produced the phenomenon, and the allele crosstalk calibration and the fragment length normalization steps did not. What would help troubleshooting is if you could see other software such as dChip of Affymetrix GTC produces the same oddities. If they do, we know for sure it's something odd with the annotation. /Henrik Any thoughts on what I'm seeing and on how the base pair normalization could cause it would be very appreciated. Thanks, Patrick -- When reporting problems on aroma.affymetrix, make sure 1) to run the latest version of the package, 2) to report the output of sessionInfo() and traceback(), and 3) to post a complete code example. You received this message because you are subscribed to the Google Groups aroma.affymetrix group with website http://www.aroma-project.org/. To post to this group, send email to aroma-affymetrix@googlegroups.com To unsubscribe and other options, go to http://www.aroma-project.org/forum/ -- When reporting problems on aroma.affymetrix, make sure 1) to run the latest version of the
