RIPSeeker multicore option not working fully?
1
0
Entering edit mode
Davis, Wade ▴ 350
@davis-wade-2803
Last seen 10.2 years ago
Dear Yue, I am using your RIPSeeker package and trying to use the option multicore=TRUE. Trying it on both windows and Linux machines, I did not observe multiple cores being used until I first called library(parallel) before running the code below. Also, it appears that only 2 cores were being used on the Linux machine, and only 1 on the windows, even though detectCores() indicated 32 cores on the Linux and 8 on the windows. Are there any additional parameters that I need to set to increase the number of cores being used? Thanks, Wade ###################################################################### ## library(ShortRead) library(RIPSeeker) library(parallel) filedir<-"~/bulkdata/PI/RIP" setwd(filedir) bamFiles <- list.files( pattern="_2\\.bam", recursive=TRUE, full.names=TRUE) cNAME <- "IgG" outDir <- file.path(filedir, "RIPSeeker_output_2") # Parameters setting binSize <- NULL # set to NULL to automatically determine bin size multicore <- TRUE # use multicore strandType <- NULL # set strand type to minus strand biomart <- "ENSEMBL_MART_ENSEMBL" # use archive to get ensembl 65 biomaRt_dataset <- "mmusculus_gene_ensembl" # mouse dataset id name goAnno <- "org.Mm.eg.db" # GO annotation database ################ run main function ripSeek to predict RIP ################ seekOut.HuR <- ripSeek(bamPath = bamFiles, cNAME = cNAME, reverseComplement = FALSE, #genomeBuild = "mm10", not relevant for BAM strandType = strandType, uniqueHit = TRUE, assignMultihits = TRUE, rerunWithDisambiguatedMultihits = TRUE, binSize=binSize, #minBinSize = minBinSize, #maxBinSize = maxBinSize, biomart=biomart, host=host, biomaRt_dataset = biomaRt_dataset, goAnno = goAnno, multicore=multicore, logOddCutoff = 2, pvalCutoff = 1, pvalAdjCutoff = 0.2, eFDRCutoff = 0.2, outDir=outDir) [[alternative HTML version deleted]]
Annotation GO RIPSeeker Annotation GO RIPSeeker • 1.4k views
ADD COMMENT
0
Entering edit mode
Dan Tenenbaum ★ 8.2k
@dan-tenenbaum-4256
Last seen 5 months ago
United States
On Wed, Jul 31, 2013 at 1:28 PM, Davis, Wade <davisjwa at="" health.missouri.edu=""> wrote: > Dear Yue, > I am using your RIPSeeker package and trying to use the option multicore=TRUE. Trying it on both windows and Linux machines, I did not observe multiple cores being used until I first called library(parallel) before running the code below. Also, it appears that only 2 cores were being used on the Linux machine, and only 1 on the windows, even though detectCores() indicated 32 cores on the Linux and 8 on the windows. > > Are there any additional parameters that I need to set to increase the number of cores being used? > I don't know about RIPSeeker in particular but it seems that it's using parallel::mclapply under the hood, so looking at ?mclapply You can see that mc.cores defaults to: mc.cores = getOption("mc.cores", 2L) Therefore you could set it as follows: options(mc.cores=detectCores()) See if that gives you different results in linux. In windows, mclapply will only work if mc.cores is set to 1. That is, it doesn't matter how many cores you have on Windows, your task will run serially. Dan > Thanks, > Wade > > #################################################################### #### > > library(ShortRead) > library(RIPSeeker) > library(parallel) > > filedir<-"~/bulkdata/PI/RIP" > setwd(filedir) > bamFiles <- list.files( pattern="_2\\.bam", recursive=TRUE, full.names=TRUE) > cNAME <- "IgG" > outDir <- file.path(filedir, "RIPSeeker_output_2") > # Parameters setting > binSize <- NULL # set to NULL to automatically determine bin size > multicore <- TRUE # use multicore > strandType <- NULL # set strand type to minus strand > biomart <- "ENSEMBL_MART_ENSEMBL" # use archive to get ensembl 65 > biomaRt_dataset <- "mmusculus_gene_ensembl" # mouse dataset id name > goAnno <- "org.Mm.eg.db" # GO annotation database > ################ run main function ripSeek to predict RIP ################ > seekOut.HuR <- ripSeek(bamPath = bamFiles, cNAME = cNAME, > reverseComplement = FALSE, #genomeBuild = "mm10", not relevant for BAM > strandType = strandType, > uniqueHit = TRUE, > assignMultihits = TRUE, > rerunWithDisambiguatedMultihits = TRUE, > binSize=binSize, > #minBinSize = minBinSize, > #maxBinSize = maxBinSize, > biomart=biomart, > host=host, > biomaRt_dataset = biomaRt_dataset, > goAnno = goAnno, > multicore=multicore, > logOddCutoff = 2, > pvalCutoff = 1, > pvalAdjCutoff = 0.2, > eFDRCutoff = 0.2, > outDir=outDir) > > > > [[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
ADD COMMENT
0
Entering edit mode
Hi Wade, As Dan mentioned, that's most likely the cost. Other than that, it would be able to use however many cores you have on the machine when multicore set TRUE. Thanks Dan. Yue On 2013-07-31, at 4:51 PM, Dan Tenenbaum <dtenenba at="" fhcrc.org=""> wrote: > On Wed, Jul 31, 2013 at 1:28 PM, Davis, Wade > <davisjwa at="" health.missouri.edu=""> wrote: >> Dear Yue, >> I am using your RIPSeeker package and trying to use the option multicore=TRUE. Trying it on both windows and Linux machines, I did not observe multiple cores being used until I first called library(parallel) before running the code below. Also, it appears that only 2 cores were being used on the Linux machine, and only 1 on the windows, even though detectCores() indicated 32 cores on the Linux and 8 on the windows. >> >> Are there any additional parameters that I need to set to increase the number of cores being used? >> > > I don't know about RIPSeeker in particular but it seems that it's > using parallel::mclapply under the hood, so looking at > ?mclapply > You can see that mc.cores defaults to: > > mc.cores = getOption("mc.cores", 2L) > > Therefore you could set it as follows: > > options(mc.cores=detectCores()) > > See if that gives you different results in linux. > > In windows, mclapply will only work if mc.cores is set to 1. That is, > it doesn't matter how many cores you have on Windows, your task will > run serially. > > Dan > > > > >> Thanks, >> Wade >> >> ################################################################### ##### >> >> library(ShortRead) >> library(RIPSeeker) >> library(parallel) >> >> filedir<-"~/bulkdata/PI/RIP" >> setwd(filedir) >> bamFiles <- list.files( pattern="_2\\.bam", recursive=TRUE, full.names=TRUE) >> cNAME <- "IgG" >> outDir <- file.path(filedir, "RIPSeeker_output_2") >> # Parameters setting >> binSize <- NULL # set to NULL to automatically determine bin size >> multicore <- TRUE # use multicore >> strandType <- NULL # set strand type to minus strand >> biomart <- "ENSEMBL_MART_ENSEMBL" # use archive to get ensembl 65 >> biomaRt_dataset <- "mmusculus_gene_ensembl" # mouse dataset id name >> goAnno <- "org.Mm.eg.db" # GO annotation database >> ################ run main function ripSeek to predict RIP ################ >> seekOut.HuR <- ripSeek(bamPath = bamFiles, cNAME = cNAME, >> reverseComplement = FALSE, #genomeBuild = "mm10", not relevant for BAM >> strandType = strandType, >> uniqueHit = TRUE, >> assignMultihits = TRUE, >> rerunWithDisambiguatedMultihits = TRUE, >> binSize=binSize, >> #minBinSize = minBinSize, >> #maxBinSize = maxBinSize, >> biomart=biomart, >> host=host, >> biomaRt_dataset = biomaRt_dataset, >> goAnno = goAnno, >> multicore=multicore, >> logOddCutoff = 2, >> pvalCutoff = 1, >> pvalAdjCutoff = 0.2, >> eFDRCutoff = 0.2, >> outDir=outDir) >> >> >> >> [[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
ADD REPLY

Login before adding your answer.

Traffic: 974 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