Question: Problem reading EPIC array data: different bead locations on different EPIC Chips
0
gravatar for m.van_iterson
2.8 years ago by
Netherlands
m.van_iterson20 wrote:

Dear list,

I came across a specific issue when reading Illumina DNA Methylation EPIC data using minfi/illuminaio. Which I could trace down to the problem of different bead locations on different chips (see output below). This has consequences for reading data using minfi (and probably other packages as well). Since, minfi, if I'm correct, assumes, featureNames (beadlocations) are the same across all idat files that are read at once.

Have people seen this before and/or how should I solve this? One ad-hoc solution I could think of is reading each chip separately and combining afterwards. A more solid solution could be reordering of bead locations of each channel e.g. in illuminaio? But this will have an effect on reading efficiency and will not always be necessary.

Regards,

Maarten van Iterson

> library(illuminaio)
> idats <- dir(pattern="idat")
> beadlocations <- simplify2array(lapply(idats, function(idat) as.integer(rownames(readIDAT(idat)$Quants))))
> colnames(beadlocations) <- basename(idats)
> head(beadlocations) ##first six bead locations of two samples from different chips
     200325570026_R01C01_Grn.idat 200325570026_R01C01_Red.idat
[1,]                      1600101                      1600101
[2,]                      1600111                      1600111
[3,]                      1600115                      1600115
[4,]                      1600123                      1600123
[5,]                      1600131                      1600131
[6,]                      1600135                      1600135
     200705860049_R01C01_Grn.idat 200705860049_R01C01_Red.idat
[1,]                      1600101                      1600101
[2,]                      1600111                      1600111
[3,]                      1600115                      1600115
[4,]                      1600123                      1600123
[5,]                      1600131                      1600131
[6,]                      1600135                      1600135
> tail(beadlocations) ##last six bead locations show the differences
           200325570026_R01C01_Grn.idat 200325570026_R01C01_Red.idat
[1052636,]                     40770147                     40770147
[1052637,]                     45656561                     45656561
[1052638,]                     71631919                     71631919
[1052639,]                     70779866                     70779866
[1052640,]                     60642867                     60642867
[1052641,]                     71726553                     71726553
           200705860049_R01C01_Grn.idat 200705860049_R01C01_Red.idat
[1052636,]                     99810956                     99810956
[1052637,]                     99810958                     99810958
[1052638,]                     99810970                     99810970
[1052639,]                     99810978                     99810978
[1052640,]                     99810990                     99810990
[1052641,]                     99810992                     99810992
> sum(beadlocations[,1] != beadlocations[,2])
[1] 0
> sum(beadlocations[,1] != beadlocations[,3]) ##but there are many more differences
[1] 1052502
> sessionInfo()
R Under development (unstable) (2016-03-21 r70361)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.4 LTS

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=en_US.UTF-8       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] illuminaio_0.14.0

loaded via a namespace (and not attached):
[1] base64_2.0    openssl_0.9.4
 

minfi illuminaio epic • 604 views
ADD COMMENTlink modified 2.8 years ago • written 2.8 years ago by m.van_iterson20
Answer: Problem reading EPIC array data: different bead locations on different EPIC Chip
1
gravatar for Kasper Daniel Hansen
2.8 years ago by
United States
Kasper Daniel Hansen6.4k wrote:
Maarten, This is specifically caused by reading in different versions of the EPIC chip in the same call. You get different versions of the same array by scanning it using different dmap files. It is unfortunate that Illumina let out >1 dmap files for the arrays into the wild and I will encourage anyone to update their scanner. Now, the issue here is that "earlier" versions of minfi did not check that all IDAT files had the exact same dimensions. This is now done in minfi 1.18.3 (or greater) or minfi 1.19.6 (or greater) which I submitted yesterday to the build system but which have yet to appear. It seems critical for EPIC users to update to these newer versions (when they appear). Or you can install from the Github repos. The read.metharray function (and friends) now work in the following way: first it tries to detect if all arrays are identical. If not, it has a new argument force (default FALSE) which will force the data into a single container, effectively only keeping probes which are present on all samples. This is done because we do not really support NAs in the raw probe intensities, so the only option is to drop them. And this is only possible if the function determines that the arrays are probably of the same type, but just different dmap files. Not for example 27k and 450k Best, Kasper On Fri, Jul 1, 2016 at 9:06 AM, m.van_iterson [bioc] < noreply@bioconductor.org> wrote: > Activity on a post you are following on support.bioconductor.org > > User m.van_iterson <https: support.bioconductor.org="" u="" 7879=""/> wrote Question: > Problem reading EPIC array data: different bead locations on different EPIC > Chips <https: support.bioconductor.org="" p="" 84531=""/>: > > Dear list, > > I came across a specific issue when reading Illumina DNA Methylation EPIC > data using minfi/illuminaio. Which I could trace down to the problem of > different bead locations on different chips (see output below). This has > consequences for reading data using minfi (and probably other packages as > well). Since, minfi, if I'm correct, assumes, featureNames (beadlocations) > are the same across all idat files that are read at once. > > Have people seen this before and/or how should I solve this? One ad-hoc > solution I could think of is reading each chip separately and combining > afterwards. A more solid solution could be reordering of bead locations of > each channel e.g. in illuminaio? But this will have an effect on reading > efficiency and will not always be necessary. > > Regards, > > Maarten van Iterson > > > library(illuminaio) > > idats <- dir(pattern="idat") > > beadlocations <- simplify2array(lapply(idats, function(idat) > as.integer(rownames(readIDAT(idat)$Quants)))) > > colnames(beadlocations) <- basename(idats) > > head(beadlocations) ##first six bead locations of two samples from > different chips > 200325570026_R01C01_Grn.idat 200325570026_R01C01_Red.idat > [1,] 1600101 1600101 > [2,] 1600111 1600111 > [3,] 1600115 1600115 > [4,] 1600123 1600123 > [5,] 1600131 1600131 > [6,] 1600135 1600135 > 200705860049_R01C01_Grn.idat 200705860049_R01C01_Red.idat > [1,] 1600101 1600101 > [2,] 1600111 1600111 > [3,] 1600115 1600115 > [4,] 1600123 1600123 > [5,] 1600131 1600131 > [6,] 1600135 1600135 > > tail(beadlocations) ##last six bead locations show the differences > 200325570026_R01C01_Grn.idat 200325570026_R01C01_Red.idat > [1052636,] 40770147 40770147 > [1052637,] 45656561 45656561 > [1052638,] 71631919 71631919 > [1052639,] 70779866 70779866 > [1052640,] 60642867 60642867 > [1052641,] 71726553 71726553 > 200705860049_R01C01_Grn.idat 200705860049_R01C01_Red.idat > [1052636,] 99810956 99810956 > [1052637,] 99810958 99810958 > [1052638,] 99810970 99810970 > [1052639,] 99810978 99810978 > [1052640,] 99810990 99810990 > [1052641,] 99810992 99810992 > > sum(beadlocations[,1] != beadlocations[,2]) > [1] 0 > > sum(beadlocations[,1] != beadlocations[,3]) ##but there are many more > differences > [1] 1052502 > > sessionInfo() > R Under development (unstable) (2016-03-21 r70361) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Ubuntu 14.04.4 LTS > > 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=en_US.UTF-8 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] illuminaio_0.14.0 > > loaded via a namespace (and not attached): > [1] base64_2.0 openssl_0.9.4 > > > ------------------------------ > > Post tags: minfi, illuminaio, epic > > You may reply via email or visit Problem reading EPIC array data: different bead locations on different EPIC Chips >
ADD COMMENTlink written 2.8 years ago by Kasper Daniel Hansen6.4k
Answer: Problem reading EPIC array data: different bead locations on different EPIC Chip
0
gravatar for m.van_iterson
2.8 years ago by
Netherlands
m.van_iterson20 wrote:

Dear Kasper,

Thanks for the explanation!

Cheers,

Maarten

 


 

ADD COMMENTlink written 2.8 years ago by m.van_iterson20
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 16.09
Traffic: 113 users visited in the last hour