<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lang.r.hpc">
    <title>gmane.comp.lang.r.hpc</title>
    <link>http://blog.gmane.org/gmane.comp.lang.r.hpc</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1064"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1063"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1062"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1053"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1052"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1049"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1029"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1022"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1015"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1012"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1005"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1004"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1001"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/1000"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/997"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/996"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/995"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/993"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/992"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.r.hpc/991"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1064">
    <title>fork() warning from mpi</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1064</link>
    <description>&lt;pre&gt;I get the following message when running a job using R 2.15.0, Rmpi, 
doMPI, and a cluster system that uses a LSF operating system and 
infiniband connections.  I'm just a user and know little about the 
workings of such networks but the warning unsettles me a little.  I've 
asked people who write and maintain open-mpi and they are suggesting 
that something has changed in the latest version of R that causes this.

I'm wondering if there has been a change or if we have done something 
incorrectly when installing Rmpi on the system, not sure here but this 
might have to be built/compiled against open-mpi libraries.  The 
open-mpi people have suggested that R must be doing some king of fork 
after the call MPI-Init.

Could anyone tell me if this is a new problem, or have we done something 
incorrectly?  I have a toy model file that creates it and am happy to 
supply this.

Thanks a bunch,

J

===============================
An MPI process has executed an operation involving a call to the
"fork()" system call to create a child process.  Open MPI is currently
operating in a condition that could result in memory corruption or
other system errors; your MPI job may hang, crash, or produce silent
data corruption.  The use of fork() (or system() or other calls that
create child processes) is strongly discouraged.

The process that invoked fork was:

   Local host:          cn149.private.dns.zone (PID 27492)
   MPI_COMM_WORLD rank: 21

If you are *absolutely sure* that your application will successfully
and correctly survive a call to fork(), you may disable this warning
by setting the mpi_warn_on_fork MCA parameter to 0.
===========================

Jim Maas
University of East Anglia
&lt;/pre&gt;</description>
    <dc:creator>Jim Maas</dc:creator>
    <dc:date>2012-05-19T14:11:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1063">
    <title>New version of cloudRmpi</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1063</link>
    <description>&lt;pre&gt;cloudRmpi v 1.2 is now available on CRAN.

cloudRmpi is a means for doing parallel processing in R, using MPI on a  
cloud-based network.  It currently
supports the use of Amazon's EC2 cloud computer service.

Changes in v 1.2:

Support for RStudio. RStudio Server is available on new AMIs.  cloudRmpi 
now has a function for securely connecting to an RStudio session running 
on the master node of an EC2-MPI network, via ssh port forwarding.  
(RStudio Server is a browser based, IDE-like interface to R).

The network specification dialog shows more information about AMIs.

The network manager has a command to repeat Open MPI network network 
configuration.


Regards,

Barnet Wagman
&lt;/pre&gt;</description>
    <dc:creator>Barnet Wagman</dc:creator>
    <dc:date>2012-05-14T16:07:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1062">
    <title>Condor, grid-appliance or pool-of-virtual machine</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1062</link>
    <description>&lt;pre&gt;Dear List,

I am hoping somebody would be kind enough to share their recent 
experiences with R and Condor or R and BOINC. I am aware of the November 
2005 RNews article, but I would think that a lot has happened in this 
area since then. E.g. The gridR package.

I am writing a preliminary report on the viability of implementing some 
form of a grid computing setup for cycle-scavanging at Rhodes 
University, South Africa. Most of our lab machines are Windows XP and 7 
desktops. My preliminary readings suggest that running a VM with Linux 
guest OS would be the best option. Is see that there are several 
pre-prepared bundles for this sort of thing, such as Grid Appliance and 
Pool-of-Virtual Machines. Has any one used any of these with R?

Any help, whatsoever, would be much appreciated.

Kind regards,

Stefan Janse van Rensburg 
&amp;lt;http://www.ru.ac.za/statistics/staff/mrstefanjansevanrensburg/&amp;gt;

&amp;lt;http://www.ru.ac.za/statistics/staff/mrstefanjansevanrensburg/&amp;gt;

Lecturer, Dept. of Statistics, Rhodes University

Tel: +27-046-603-8682

--

Visit my public photo album... 
&amp;lt;https://picasaweb.google.com/102772614620404730049?feat=email&amp;gt;




[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Stefan Janse van Rensburg</dc:creator>
    <dc:date>2012-05-14T11:08:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1053">
    <title>Quickest way to make a large "empty" file on disk?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1053</link>
    <description>&lt;pre&gt;R-helpers:

What would be the absolute fastest way to make a large "empty" file (e.g.
filled with all zeroes) on disk, given a byte size and a given number
number of empty values.  I know I can use writeBin, but the "object" in
this case may be far too large to store in main memory.  I'm asking because
I'm going to use this file in conjunction with mmap to do parallel writes
to this file.  Say, I want to create a blank file of 10,000 floating point
numbers.

Thanks!

--j

&lt;/pre&gt;</description>
    <dc:creator>Jonathan Greenberg</dc:creator>
    <dc:date>2012-05-02T22:23:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1052">
    <title>Analytics &amp; Data Mining Conference, San Diego,California</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1052</link>
    <description>&lt;pre&gt;Subject: Analytics &amp;amp; Data Mining Conference, San Diego, California

Don't miss it, it's this month!

The 2012 Salford Analytics &amp;amp; Data Mining Conference aims to bring together
researchers, practitioners, and data enthusiasts to exchange ideas and
experiences.

Attendees will have the chance to have one-on-one meetings with the creators of the CART and RandomForests algorithms
(Dr. Adele Cutler, Dr. Jerome Friedman and Dr. Richard Olshen).

In addition, the following companies will give presentations:
Johnson &amp;amp; Johnson, Genentech, Visa, Fidelity, Qualcomm, Union Bank and more!

Conference website: http://www.salforddatamining.com/
Agenda: http://www.salforddatamining.com/agenda.html
Registration: http://www.salforddatamining.com/register.html

For additional information, contact info-JdWS0y8hGXeRvUXW8jGz4vpXobYPEAuW&amp;lt; at &amp;gt;public.gmane.org&amp;lt;mailto:info-JdWS0y8hGXeRvUXW8jGz4vpXobYPEAuW&amp;lt; at &amp;gt;public.gmane.org&amp;gt; or phone 619-543-8880.

Best regards,
Lisa Solomon
lisas-8ugdV5V/5NuhEniVeURVKkEOCMrvLtNR&amp;lt; at &amp;gt;public.gmane.org&amp;lt;mailto:lisas-8ugdV5V/5NuhEniVeURVKkEOCMrvLtNR&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Salford Systems

[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Lisa Solomon</dc:creator>
    <dc:date>2012-05-02T19:08:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1049">
    <title>'Rmpi' issue</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1049</link>
    <description>&lt;pre&gt;Hi,

I am trying to test 'Rmpi' on Blacklight,
http://www.psc.edu/machines/sgi/uv/blacklight.php, in PSC.

The R code I am trying to run is very simple:

mpi.remote.exec(paste("I am",mpi.comm.rank(),"of",mpi.comm.size()))
mpi.remote.exec(paste("I am",Sys.info()1,"of",mpi.comm.size()))

The batch file:

#!/bin/csh
#PBS -l walltime=5:00
#PBS -l ncpus=16
#PBS -o test.out
#PBS -j oe
#PBS -q debug

# define module command
source /usr/share/modules/init/csh

set echo
date

# load R module
module load R/2.11.1
module load Rmpi
module swap mpt/2.04 mpt/2.01

# move to scratch space to run job
cd $SCRATCH

# copy input file to scratch space
cp $HOME/test.R .
cp $HOME/.Rprofile .

mpirun -np 16 R --no-save -q &amp;lt; test.R &amp;gt; test.Rout

However, here are some error messages I got:

 *** caught segfault ***
address (nil), cause 'memory not mapped'

Traceback:
 1: dyn.load(file, DLLpath = DLLpath, ...)
 2: library.dynam("Rmpi", pkg, lib)
 3: f(libname, pkgname)
 4: firstlib(which.lib.loc, package)
 5: doTryCatch(return(expr), name, parentenv, handler)
 6: tryCatchOne(expr, names, parentenv, handlers[[1L]])
 7: tryCatchList(expr, classes, parentenv, handlers)
 8: tryCatch(expr, error = function(e) {    call &amp;lt;- conditionCall(e)    if
(!is.null(call)) {        if (identical(call[[1L]],
quote(doTryCatch)))             call &amp;lt;- sys.call(-4L)        dcall &amp;lt;-
deparse(call)[1L]        prefix &amp;lt;- paste("Error in", dcall, ": ")
LONG &amp;lt;- 75L        msg &amp;lt;- conditionMessage(e)        sm &amp;lt;- strsplit(msg,
"\n")[[1L]]        w &amp;lt;- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type
= "w")        if (is.na(w))             w &amp;lt;- 14L + nchar(dcall, type = "b")
+ nchar(sm[1L],                 type = "b")        if (w &amp;gt;
LONG)             prefix &amp;lt;- paste(prefix, "\n  ", sep = "")    }    else
prefix &amp;lt;- "Error : "    msg &amp;lt;- paste(prefix, conditionMessage(e), "\n", sep
= "")    .Internal(seterrmessage(msg[1L]))    if (!silent &amp;amp;&amp;amp;
identical(getOption("show.error.messages"),         TRUE)) {
cat(msg, file = stderr())        .Internal(printDeferredWarnings())    }
invisible(structure(msg, class = "try-error"))})
 9: try(firstlib(which.lib.loc, package))
10: library(Rmpi, logical.return = TRUE)
aborting ...

Any idea how to fix this?

Many thanks,
Libo

[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Libo Sun</dc:creator>
    <dc:date>2012-04-30T04:07:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1029">
    <title>parallel and openblas</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1029</link>
    <description>&lt;pre&gt;Parallel and openblas don't seem to mix well on my machine. If I link openblas, a job executed through parallel (using either the multicore or snow (local socket cluster) setup), each of my 8 cores only operates at 1/8 of 100% (taking a little longer than serial execution). Linking to the reference blas or to single-threaded atlas does not cause this handicap when running snow or multicore. 

Is this a known problem (My google attempts were fruitless)? If yes, is there a fix for it? Do MKL or multi-threaded atlas have the same issues? 

Thank you for your time. 

Martin



Martin Renner
Post-doctoral Fellowphone: 907-226 4672
University of Washington   or: 907-235 0728
School of Aquatic and Fishery SciencesSeattle, USA





debian squeeze on 8-core Xeon
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     
&lt;/pre&gt;</description>
    <dc:creator>Martin Renner</dc:creator>
    <dc:date>2012-04-23T19:53:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1022">
    <title>What to Experiment With?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1022</link>
    <description>&lt;pre&gt;Dear R HPC experts:

I have about $5,000 to spend on building fast computer hardware to run
our problems.  if it works well, I may be able to scrounge up another
$10k/year to scale it up.  I do not have the resources to program very
complex algorithms, administer a full cluster, etc.  (the effective
programmer's rate here is about $50/hour and up, and I have severe
restrictions against hiring outsiders.)  the programs basically have
to work with minimum special tweaking.

There are no real-time needs.  Typically, I operate on historical CRSP
and Compustat data, which are about 1-5GB (depending on subset).  most
of what I am doing involves linear regressions.  I often need to
calculate Newey-West/Hansen-Hodrick/White adjusted standard errors,
and I often do need to sort and rank, calculate means and covariances.
 these are not highly sophisticated stats, but it entails lots of it.
most of what I do is embarrassingly parallel.

Now, I think in the $5k price range, I have a couple of options.
Roughly, the landscape seems to be:

* 1 dual-socket xeon i7 computers.
* 5 (desktop) i7 computers, networked (socket snow?).
* 1 i7 computer, with 1 nvidia Tesla card
* 1 i7 computers with 2-3 commodity graphics cards
     --- apparently, nvidia cripples the DP performance of its gamer
cards, so AMD should be a *lot* faster
     at the same price, but I only see the lm() routine in
nvidia-specific gputools.  then again, for Newey-West,
     I may have to resort to my own calculations, anyway.  is there
newey-west OLS code for AMD GPUs?

I would presume that an internal PCI bus is a lot faster than an
ethernet network, and a GPU could be faster than a CPU, but a GPU is
also less flexible.  Sigh...not sure.
what should I try?

/iaw


----
Ivo Welch (ivo.welch-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org)
&lt;/pre&gt;</description>
    <dc:creator>ivo welch</dc:creator>
    <dc:date>2012-04-20T22:16:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1015">
    <title>What happened to the vignette of 'parallel'?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1015</link>
    <description>&lt;pre&gt;Hi,

I am looking for the latest version of the vignette of 'parallel'. I can't find
it (not on CRAN, not via vignette()). How can I obtain it?

Cheers,

Marius
&lt;/pre&gt;</description>
    <dc:creator>Marius Hofert</dc:creator>
    <dc:date>2012-04-15T00:03:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1012">
    <title>compiling R 2.15.0 to link to open MPI</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1012</link>
    <description>&lt;pre&gt;I use R in parallel on a cluster.  Our Sys Op has compiled the versions 
for me, up to R 2.13.1 against openMPI libraries so that I can run 
programmes across 404 cores.  I've just asked him to compile 2.15 for me 
but he can't find how to connect it to openMPI.  Has that capability 
disappeared or has the method of connecting changed?

Thanks

J

&lt;/pre&gt;</description>
    <dc:creator>Jim Maas</dc:creator>
    <dc:date>2012-04-11T11:28:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1005">
    <title>libRblas.so =&gt; not found problem</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1005</link>
    <description>&lt;pre&gt;r-sig-hpc'ers:

I'm banging my head against a wall with this.  I recently updated R to 2.15 via:

./configure --prefix=/pathtoinstall/ --enable-R-shlib --enable-BLAS-shlib
make
make install

I noticed that I wasn't getting a multithreaded response on, e.g.:
a = matrix(rnorm(5000*5000), 5000, 5000)
b = matrix(rnorm(5000*5000), 5000, 5000)
c = a%*%b

[This used to light up all 12 cores on our system, now it only lights
up one and takes MUCH longer].

I have an update-alternatives set up for /pathto/R/lib/libRblas.so (I
backed up the installed one to libRblas.so_bak) where I have a few
flavors of BLAS I've been playing with (including one that USED to
work, an alpha of OpenBLAS).  I also have the most recent OpenBLAS and
Intel MKL.  The update-alternatives IS working.

When I ldd R I see I no longer have a link to libRblas.so:
 ldd /pathto/R/bin/exec/R
        linux-vdso.so.1 =&amp;gt;  (0x00007fffd4a9e000)
        libR.so =&amp;gt; not found
        libRblas.so =&amp;gt; not found
        libgomp.so.1 =&amp;gt; /usr/lib64/libgomp.so.1 (0x00007f6b80bf4000)
        libpthread.so.0 =&amp;gt; /lib64/libpthread.so.0 (0x00007f6b809d8000)
        libc.so.6 =&amp;gt; /lib64/libc.so.6 (0x00007f6b80649000)
        librt.so.1 =&amp;gt; /lib64/librt.so.1 (0x00007f6b80441000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6b80e01000)

Nothing I do seems to re-link this, and even downgrading back to R
2.14.2 hasn't fixed this.  I even removed the /pathto/R directory to
attempt a "clean" install.   FYI: I am on a system that MUST have R
compiled from scratch, so I can't use any pre-existing binaries.
Thoughts?

--j

&lt;/pre&gt;</description>
    <dc:creator>Jonathan Greenberg</dc:creator>
    <dc:date>2012-04-05T16:32:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1004">
    <title>parallel and snow</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1004</link>
    <description>&lt;pre&gt;r-sig-hpc'ers:

Now that parallel is coming along with R, has anyone written a summary
of how it compares?  Should I be using snow or parallel for (e.g.)
clusterMap() calls?

--j

&lt;/pre&gt;</description>
    <dc:creator>Jonathan Greenberg</dc:creator>
    <dc:date>2012-04-03T20:21:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1001">
    <title>Rmpi spawning across nodes.</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1001</link>
    <description>&lt;pre&gt;Hello all,

I've seen multiple posts on this subject, but haven't clearly been able to
understand the issue. There must be something small.

I am trying to get Rmpi, foreach and snow working on a beowulf cluster,
using debian.

I have succeeded in installing Rmpi, changing the paths, etc.

However, i remain the with my original problem, when

cl&amp;lt;-makeCluster(4,type="MPI")

spawns slaves, they are always on the same node!

There are two processor per node on my cluster. What i need is a way to
spawn slaves across all nodes i've requested in my qsub script.

export PATH=$PATH:/usr/local/pkg/openmpi-1.4.4/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pkg/openmpi-1.4.4/lib
#!/bin/bash
#PBS -o 'qsub.out'
#PBS -e 'qsub.err'
#PBS -l nodes=4:ppn=1
#PBS -m bea
$PBS_NODEFILE
$hostname

cd $PBS_O_WORKDIR

# Run an R script
R --vanilla &amp;lt; /nfs/user08/bw4sz/Files/Seawulf.R &amp;gt; output.Rout

I have tried using mpirun -np 4 in front of the R - call, but this just
fails without message.

In my R script, i call (alot of things, just the meat shown below).

cl &amp;lt;- makeCluster(4, type = "MPI")
print(clusterCall(cl,function() Sys.info()[c("nodename","machine")])) #This
always gives me the same nodenames, just on of the nodes in the Pbs
nodefile (and no, not the head node).

registerDoSNOW(cl)
print(getDoParWorkers())
system.time(five.ten &amp;lt;- rbind.fill(foreach(j=1:times ) %dopar%
drop.shuffle(j,iterations))) # Parameters are defined elsewhere, this is
not the issue.
stopCluster(cl)


My dream scenerio is to use both processors on each node, and pass
information between nodes in separate workflows.

I appreciate any suggestions

There is nothing wrong with my R script in terms of code, it works great
using doMC and foreach, with 8 cores on my desktop. However, i have not
been able to register the correct cores when using the University Cluster.

I am new at this, please forgive my lack of precise terms.

Best,

Ben Weinstein
&lt;/pre&gt;</description>
    <dc:creator>Ben Weinstein</dc:creator>
    <dc:date>2012-03-29T18:26:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/1000">
    <title>spawning MPI workers through RDCOM on Windows 7</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/1000</link>
    <description>&lt;pre&gt;Hello,

I am having performance issues using Statconnector, working on Windows 7,
Intel(R) Core(TM) i7. CPU &amp;lt; at &amp;gt; 2.69GHz. operating on a 64-bit. After reading
archives and docs about Parallel R, I have installed the following Rmpi and
Snow packages:

   * &amp;gt; sessionInfo()
    R version 2.13.1 Patched (2011-07-22 r56481)
    Platform: i386-pc-mingw32/i386 (32-bit)

    locale:
    [1] LC_COLLATE=English_United Kingdom.1252
    [2] LC_CTYPE=English_United Kingdom.1252
    [3] LC_MONETARY=English_United Kingdom.1252
    [4] LC_NUMERIC=C
    [5] LC_TIME=English_United Kingdom.1252

    attached base packages:
    [1] stats     graphics  grDevices datasets  utils     methods
base

    other attached packages:
    [1] Rmpi_0.5-9     rcom_2.2-3.1   rscproxy_1.3-1

    loaded via a namespace (and not attached):
    [1] tools_2.13.1*

Spawning for workers, I have the following:

*    mpi.spawn.Rslaves(nslaves=2, needlog=TRUE)
    2 slaves are spawned successfully. 0 failed.
    master (rank 0, comm 1) of size 3 is running on: Y-PC
    slave1 (rank 1, comm 1) of size 3 is running on: Y-PC
    slave2 (rank 2, comm 1) of size 3 is running on: Y-PC*

Everything seems to be working fine from R. But trying to spawn the cores
through Statconnector seems to fail (freeze). I have removed all firewalls.
Testing the same program with type = "SOCK" (which does not involve Rmpi)
works perfectly:

*    sc.EvaluateNoReturn("c1 &amp;lt;- makeCluster( 10 , type = \"SOCK\")");
    sc.EvaluateNoReturn("res &amp;lt;- parLapply(c1, list,  fun)");*



The cluster options seem correctly identified through RDCOM:
*        "test &amp;lt;- getClusterOption(\"port\")"
    "10187"
*
*        "test1 &amp;lt;- getClusterOption(\"snowlib\")"**
    "C:/PROGRA~1/R/R-213~1.1/library"*
*
        "test2 &amp;lt;- getClusterOption(\"rscript\")"
    "C:/PROGRA~1/R/R-213~1.1/bin/Rscript.exe"*

But given the number of simulations I have to run (up to 1000 simulations *
1000  optimisation problems using quadprog::solve), using more processors
would be a relief.

I am using the 32-bit R which works well with Statconnector. installed
MPICH2 which is correctly configured given the successful MPI workers
detection from R.

Then trying the following is failing (the application is hanging):

*    sc.EvaluateNoReturn("mpi.spawn.Rslaves(nslaves=2, needlog=TRUE)");
*
    or

*    sc.EvaluateNoReturn("c &amp;lt;- makeCluster(mpi.universe.size() - 1, type =
"MPI")")*
Is it possible to use MPI on Windows 7 through an R session initiated via
R(D)COM?

Many Thanks,
Yves

[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Y R</dc:creator>
    <dc:date>2012-03-29T05:31:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/997">
    <title>New AMD Bulldozer for Parallel Computing with R</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/997</link>
    <description>&lt;pre&gt;Dear R enthusiasts,

i`m planning to set up a new PC and consider to buy an AMD FX-8120. For 
my estimations (with floating-point data) I use the genoud optimizer in 
the package rgenoud which (at least I think) would be able to handle the 
8 cores. Is anybody using the AMD proc for computing with R and could 
tell about the performance? What scares me a bit to just buy it are the 
huge amount of benchmarks on the net which tell that AMD has really bad 
performance ( especially for single-threaded apps). Would the Intel I7 
2600 be the better alternative? All the Intel 6-core processors are out 
of budget for me.

Best regards,

Andreas Recktenwald

&lt;/pre&gt;</description>
    <dc:creator>Andreas Recktenwald</dc:creator>
    <dc:date>2012-03-23T11:14:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/996">
    <title>indexing/mmap database package</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/996</link>
    <description>&lt;pre&gt;Hi,

I try to understand the indexing package operation. I want to store data
from a C-apps on disk to be able to natively read it into R with
indexing/mmap (and vice versa from R-indexing to C-apps). If I understand
correctly, we have:

 # each column in the envir contains a list of entries:
    #  d: original data mapping
    #  s: sorted data
    #  o: ordered data (location of sorted in data)

We use binsearch() to find index for "value" in sorted data:

binsearch(value, sorted[], n) -&amp;gt; return sorted_idx;

then we use the sorted_idx as a index in ordered data to locate index in
original data:

ordered [sorted_idx] -&amp;gt; return idx;

original [idx]  -&amp;gt; return value;


Is this how it works?

Best regards,
Daniel

[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Daniel Cegiełka</dc:creator>
    <dc:date>2012-03-20T11:33:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/995">
    <title>generate a DLL on 64-bit windows</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/995</link>
    <description>&lt;pre&gt;Hi everyone,

Our team is trying to compile a numerical optimization library that we use with our R package (OpenMx). We've been able to compile it on all platforms + architectures except for 64-bit windows. The library is written in fortran (I think it was written in the Fortran 77 dialect and we're using gfortran to compile it). I've tried compiling with the Rtools 2.14 suite and I get the following segfault captured below in gdb when I try to use the library. I'm using R CMD SHLIB to build the dll. I've also tried using the Rtools 2.15 suite and the resulting .dll crashes on both 32-bit and 64-bit platforms (I haven't run gdb on those crashes, that is on the TO DO list). Has anyone experienced the following error?

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000772440c0 in ntdll!RtlUnicodeToCustomCPN ()
  from C:\Windows\system32\ntdll.dll


[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Michael Spiegel</dc:creator>
    <dc:date>2012-03-16T17:24:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/993">
    <title>Question about output the objects on slave by SNOW</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/993</link>
    <description>&lt;pre&gt;Hi all,

I am using SNOW package on my multi-core Windows machine. I am wondering if
there is a way to output the objects on slave, as far as I know 'cat' or
'print' doesn't work. One simple example:

+ y=sin(x)
+ cat('x=', x,'\n')
+ return(y)
+ }
[1] 0.841471 0.841471

I would like to get the information about 'x', like this,

x= 1
x= 1
[1] 0.841471 0.841471

Thanks,
Libo

[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Libo Sun</dc:creator>
    <dc:date>2012-03-16T16:23:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/992">
    <title>a CUDA question solved</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/992</link>
    <description>&lt;pre&gt;Hello again:

I found all of my answers (at least for a little while) on the following website:

http://possiblybrainful.blogspot.com/2011/08/using-gpu-in-r-scripts.html

Thanks,
Erin


Erin M. Hodgess, PhD
Associate Professor
Department of Computer and Mathematical Sciences
University of Houston - Downtown
mailto: hodgesse-aB/zTajLQNc&amp;lt; at &amp;gt;public.gmane.org


[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Hodgess, Erin</dc:creator>
    <dc:date>2012-03-15T22:29:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/991">
    <title>a CUDA question</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/991</link>
    <description>&lt;pre&gt;Dear R SIG HPC:

I have a CUDA question, please:  I have a small subroutine (stolen from the Extensions manual) and fixed for CUDA

#include &amp;lt;R.h&amp;gt;
#include &amp;lt;Rinternals.h&amp;gt;

__global__ void conv1(double *a, int *na, double *b, int *nb, double *ab)
{
R_len_t i, j, nab = *na + *nb - 1;
for(i = 0; i &amp;lt; nab; i++)
ab[i] = 0.0;
for(i = 0; i &amp;lt; *na; i++)
for(j = 0; j &amp;lt; *nb; j++)
ab[i + j] += a[i] * b[j];
}

and its name is conv1.cu

I then have a Makefile:
EXT := cu 

OBJS := conv1.o

#compiler/preprocessor options
INCS := -I/usr/local/cuda/include
PARAMS := -Xcompiler "-I/usr/share/R/include -fpic"

#linker options
LD_PARAMS := -Xlinker "-L/usr/lib/R/lib -lR -Wl,-rpath,/usr/local/cuda/lib64"
LIBS :=  -L/usr/local/cuda/lib64 -lcublas -L/usr/lib/nvidia-current/-lcuda

TARGETS := conv1.so

CC := /usr/local/cuda/bin/nvcc

all: $(TARGETS) 

$(TARGETS): $(OBJS)
$(CC) -shared $(LD_PARAMS) $(LIBS) $(OBJS) -o $&amp;lt; at &amp;gt;

$(OBJS): %.o: %.$(EXT)
$(CC) -c $(INCS) $(PARAMS) $^ -o $&amp;lt; at &amp;gt;

clean:
rm -rf *o

.PHONY: all clean

And when I run make, all is well:
erin&amp;lt; at &amp;gt;ubuntu:~$ make
/usr/local/cuda/bin/nvcc -shared -Xlinker "-L/usr/lib/R/lib -lR -Wl,-rpath,/usr/local/cuda/lib64" -L/usr/local/cuda/lib64 -lcublas -L/usr/lib/nvidia-current/-lcuda conv1.o -o conv1.so
erin&amp;lt; at &amp;gt;ubuntu:~$ 


then I go to R
[1] FALSE

Do you have any idea what I'm doing wrong, please?

Thanks for any help!
Sincerely,
Erin


Erin M. Hodgess, PhD
Associate Professor
Department of Computer and Mathematical Sciences
University of Houston - Downtown
mailto: hodgesse-aB/zTajLQNc&amp;lt; at &amp;gt;public.gmane.org


[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Hodgess, Erin</dc:creator>
    <dc:date>2012-03-15T21:30:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.r.hpc/982">
    <title>Debian/Ubuntu + threaded BLAS/ATLAS (solved)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.r.hpc/982</link>
    <description>&lt;pre&gt;I thought I'll post this here since I could not find an answer anywhere I searched: how to setup R with threaded BLAS on Debian/Ubuntu.

First, neither Debian nor Ubuntu come with optimized ATLAS binaries, simply because by definition they need to be optimized for a particular machine. The good news: it is easy to build:

apt-get source atlas
cd atlas-3.*
# less debian/README.Debian # read the docs - it's short
# sudo apt-get build-dep atlas # &amp;lt;- you may need this if you don't have all tools installed
fakeroot debian/rules custom

That will give you (after a long while) a bunch of libatlas*.deb files that you can easily install with sudo dpkg -i 

Now if you simply configure R --with-blas --with-lapack it will work, and you'll get a nice and fast BLAS, but unfortunately it will be single-threaded:

   user  system elapsed 
  0.684   0.012   0.697 

The problem is that all those nice libraries that are handled by update-alternatives are just the single-threaded part of ATLAS. If you want to use the parallelized part, you'll need to add the libpt* libraries by hand. This worked for me:

--with-blas='/usr/lib/atlas-base/libptcblas.a /usr/lib/atlas-base/libptf77blas.a /usr/lib/atlas-base/libatlas.a -lpthread -lm' --with-lapack

I opted for using the static version of ATLAS, but you can equally well use the shared one.

   user  system elapsed 
  1.548   0.068   0.133 

Note that by default it will use all cores. You can add "-t N" to the atlas configure flags in debian/rules if you want to change that (e.g. if you want to combine it with explicit parallelization).

I'm simply sharing this in the hope that it will be helpful - please no flames ;).

Cheers,
Simon
&lt;/pre&gt;</description>
    <dc:creator>Simon Urbanek</dc:creator>
    <dc:date>2012-03-15T03:09:59</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.r.hpc">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.r.hpc</link>
  </textinput>
</rdf:RDF>

