similar to: assigning vector or matrix sparsely (for use with mclapply)

Hi, This is my code (my data is attached): library(languageR) library(rms) library(party) OLDDATA <- read.csv("/Users/Abigail/Documents/OldData250412.csv") OLDDATA$YD <- factor(OLDDATA$YD, label=c("Yes", "No"))? OLDDATA$ND <- factor(OLDDATA$ND, label=c("Yes", "No"))? attach(OLDDATA) defaults <- cbind(YD, ND) set.seed(47) data.controls

Hi I have just moved our 400 TB HPC storage from lustre to gluster. It is part of a research institute and users have very small files to big files ( few KB to 20GB) . Our setup consists of 5 servers, each with 96TB RAID 6 disks. All servers are connected through 10G ethernet but not all clients. Gluster volumes are distributed without any replication. There are approximately 80 million files in

Isn't anything in a data frame that is not explicitly numeric a *factor*? -Greg > -----Original Message----- > From: Peter Dalgaard BSA [mailto:p.dalgaard@biostat.ku.dk] > Sent: Friday, December 07, 2001 5:32 PM > To: Erich Neuwirth > Cc: r-devel@stat.math.ethz.ch > Subject: Re: [Rd] question > > > Erich Neuwirth

Can you please provide more details about your volume configuration and the version of gluster that you are using? Regards, Vijay On Fri, Jun 9, 2017 at 5:35 PM, mohammad kashif <kashif.alig at gmail.com> wrote: > Hi > > I have just moved our 400 TB HPC storage from lustre to gluster. It is > part of a research institute and users have very small files to big files > ( few

Hi Vijay Thanks for your quick response. I am using gluster 3.8.11 on Centos 7 servers glusterfs-3.8.11-1.el7.x86_64 clients are centos 6 but I tested with a centos 7 client as well and results didn't change gluster volume info Volume Name: atlasglust Type: Distribute Volume ID: fbf0ebb8-deab-4388-9d8a-f722618a624b Status: Started Snapshot Count: 0 Number of Bricks: 5 Transport-type: tcp

Hi, We have outdated SOA information in our samba DNS. We used to have a DC1, and it is no more, however it's listed in our SOA records on both remaining DC's. I think this is not correct. I am under the impression that in order to get full failover support, all DC's need to have listed themselves as SOA. This is also what google tells me:

Hi Vijay I have enabled client profiling and used this script https://github.com/bengland2/gluster-profile-analysis/blob/master/gvp-client.sh to extract data. I am attaching output files. I don't have any reference data to compare with my output. Hopefully you can make some sense out of it. On Sat, Jun 10, 2017 at 10:47 AM, Vijay Bellur <vbellur at redhat.com> wrote: > Would it be

Would it be possible for you to turn on client profiling and then run du? Instructions for turning on client profiling can be found at [1]. Providing the client profile information can help us figure out where the latency could be stemming from. Regards, Vijay [1] https://gluster.readthedocs.io/en/latest/Administrator%20Guide/Performance%20Testing/#client-side-profiling On Fri, Jun 9, 2017 at

Hi, sorry, I'm an idiot.. and I know I'm missing something stupid.. I thought if we solve an underdetermine system with QR, my soln is: min ||x|| (L2 sense) such that Ax = b then say i have: > w <- matrix(c(1, 5), ncol=2) > sw = 2 > qrW = qr(t(w) %*% w) > qr.coef(qrW, t(w) %*% sw) [,1] [1,] 2 [2,] NA but we also have soln (0, 2/5) which obviously has a

Hi Vijay Did you manage to look into the gluster profile logs ? Thanks Kashif On Mon, Jun 12, 2017 at 11:40 AM, mohammad kashif <kashif.alig at gmail.com> wrote: > Hi Vijay > > I have enabled client profiling and used this script > https://github.com/bengland2/gluster-profile-analysis/blob/ > master/gvp-client.sh to extract data. I am attaching output files. I >

I've been using mclapply and have encountered situations where it gives errors or returns incorrect results. Here's a minimal example, which gives the error on R 2.15.2 on Mac and Linux: library(parallel) f <- function(x) NULL mclapply(1, f, mc.preschedule = FALSE, mc.cores = 1) # Error in sum(sapply(res, inherits, "try-error")) : # invalid 'type' (list) of argument

for the googleable r-help archives, I thought I would post what I wrote into my .Rprofile to automatically set some system information. the most relevant aspect is the determination of mc.cores. this is useful when users want to use the parallel package options(uname= system("uname", intern=TRUE)) options(os= if (getOption("uname")=="Darwin") "osx"

Hi Mohammad, A lot of time is being spent in addressing metadata calls as expected. Can you consider testing out with 3.11 with md-cache [1] and readdirp [2] improvements? Adding Poornima and Raghavendra who worked on these enhancements to help out further. Thanks, Vijay [1] https://gluster.readthedocs.io/en/latest/release-notes/3.9.0/ [2] https://github.com/gluster/glusterfs/issues/166 On

Dear members, I am using arfima in an mclapply construction (from the parallel package): Browse[2]> LYG <- mclapply(LYGH, FUN = arfima, mc.cores = detectCores()) ^C Browse[2]> LYG <- mclapply(LYGH[1:10], FUN = arfima, mc.cores = detectCores()) ^C Browse[2]> LYG <- mclapply(LYGH[1:2], FUN = arfima, mc.cores = detectCores()) ^C You can see that I am

dear R readers---I thought I would post the following snippet of R code that makes by() like operations easier and faster on multicore machines for R novices and amateurs. I hope it helps some. YMMV. feel free to ignore. PS: I wish R had a POD-like documentation system for end users that are not writing full libraries. because it does not, I did not provide documentation ala '?mc.by'.

Hello, I have been having issues using parallel::mclapply in a memory-efficient way and would like some guidance. I am using a 40 core machine with 96 GB of RAM. I've tried to run mclapply with 20, 30, and 40 mc.cores and it has practically brought the machine to a standstill each time to the point where I do a hard reset. When running mclapply with 10 mc.cores, I can see that each process

Dear parallel users and developers, I might have encountered a bug in the function 'mclapply' of package 'parallel'. I construct a matrix using the same input data and code with a single difference: Once I use mclapply and the other time lapply. Shockingly the result is NOT the same. To evaluate please unpack the attached archive and execute Rscript mclapply_test.R I put the

Dear R-devel friends: I'm back to bother you again about the conflict between mclapply and tcltk. I've been monitoring several packages that want to use mclapply to parallelize computations and need to figure out what should be done. It appears tcltk cannot be safely unloaded, so the best we can do is check for the presence of tcltk and stop if it is found before mclapply() is used. I

On Sat, 13 Apr 2019 at 03:51, Kevin Ushey <kevinushey at gmail.com> wrote: > > I think it's worth saying that mclapply() works as documented Mostly, yes. But it says nothing about fork's copy-on-write and memory overcommitment, and that this means that it may work nicely or fail spectacularly depending on whether, e.g., you operate on a long vector. -- I?aki ?car

Just throwing my two cents in: I think removing/deprecating fork would be a bad idea for two reasons: 1) There are no performant alternatives 2) Removing fork would break existing workflows Even if replaced with something using the same interface (e.g., a function that automatically detects variables to export as in the amazing `future` package), the lack of copy-on-write functionality would