Hmmm...okay, I understand the scenario. Must be something in the algo when it
only has one node, so it shouldn't be too hard to track down.
I'm off on travel for a few days, but will return to this when I get back.
Sorry for delay - will try to look at this while I'm gone, but can't promise
any
Hi Ralph, sorry for confusing.
We usually logon to "manage", which is our control node.
>From manage, we submit job or enter a remote node such as
node03 by torque interactive mode(qsub -I).
At that time, instead of torque, I just did rsh to node03 from manage
and ran myprog on the node. I hope
On Dec 10, 2013, at 6:05 PM, tmish...@jcity.maeda.co.jp wrote:
>
>
> Hi Ralph,
>
> I tried again with -cpus-per-proc 2 as shown below.
> Here, I found that "-map-by socket:span" worked well.
>
> [mishima@node03 demos]$ mpirun -np 8 -report-bindings -cpus-per-proc 2
> -map-by socket:span mypro
Hi Ralph,
I tried again with -cpus-per-proc 2 as shown below.
Here, I found that "-map-by socket:span" worked well.
[mishima@node03 demos]$ mpirun -np 8 -report-bindings -cpus-per-proc 2
-map-by socket:span myprog
[node03.cluster:10879] MCW rank 2 bound to socket 1[core 8[hwt 0]], socket
1[core
Hmmm...that's strange. I only have 2 sockets on my system, but let me poke
around a bit and see what might be happening.
On Dec 10, 2013, at 4:47 PM, tmish...@jcity.maeda.co.jp wrote:
>
>
> Hi Ralph,
>
> Thanks. I didn't know the meaning of "socket:span".
>
> But it still causes the problem,
Hi Ralph,
Thanks. I didn't know the meaning of "socket:span".
But it still causes the problem, which seems socket:span doesn't work.
[mishima@manage demos]$ qsub -I -l nodes=node03:ppn=32
qsub: waiting for job 8265.manage.cluster to start
qsub: job 8265.manage.cluster ready
[mishima@node03 ~]
No, that is actually correct. We map a socket until full, then move to the
next. What you want is --map-by socket:span
On Dec 10, 2013, at 3:42 PM, tmish...@jcity.maeda.co.jp wrote:
>
>
> Hi Ralph,
>
> I had a time to try your patch yesterday using openmpi-1.7.4a1r29646.
>
> It stopped the e
Hi Ralph,
I had a time to try your patch yesterday using openmpi-1.7.4a1r29646.
It stopped the error but unfortunately "mapping by socket" itself didn't
work
well as shown bellow:
[mishima@manage demos]$ qsub -I -l nodes=1:ppn=32
qsub: waiting for job 8260.manage.cluster to start
qsub: job 826
Thanks Jeff,
It turns out this was an issue with Homebrew (package manager for mac) and
not related to open-mpi...
If any Homebrew users have this issue in the future when installing
open-mpi here's what happened: there were some non-Homebrewed 32-bit
gfortran libraries floating around in the lib
George Bosilca writes:
>> No. The Fortran status must __always__ be 6, because we need enough room to
>> correctly convert the 3 useful variables to Fortran, plus copy the rest of
>> the hidden things.These 6 type will be INTEGER (which will then be different
>> than the C int). The C<->F stuf
Please send all the information listed here:
http://www.open-mpi.org/community/help/
On Dec 10, 2013, at 5:49 AM, 周文平 wrote:
>
>
> -- Forwarded message --
> From: 周文平
> Date: 2013/12/10
> Subject: Open MPI can't launch remote nodes via SSH
> To: devel
>
>
> I am tryin
-- Forwarded message --
From: 周文平
List-Post: users@lists.open-mpi.org
Date: 2013/12/10
Subject: Open MPI can't launch remote nodes via SSH
To: devel
I am trying to set up Open MPI between a few machines on out network. Open
MPI works fine locally, but I just can't get it to work
12 matches
Mail list logo
