So, I tried out the flag that you mentioned would force the use of loopback
interface. It worked without error or stalling:
$ )mpirun --mca oob_tcp_if_include lo0 -np 2 ./hello_cxx
Hello, world! I am 0 of 2(Open MPI v1.7.3, package: Open MPI
macpo...@meredithk-mac.corp.fmglobal.com Distributio
On Dec 4, 2013, at 7:25 AM, "Meredith, Karl" wrote:
> Before turning off my firewall, I have these rules
>
> $ )sudo ipfw list
> Password:
> 05000 allow ip from any to any via lo*
This is an interesting rule. Perhaps you can try:
mpirun --mca oob_tcp_if_include lo0 ...
Which would force
Yeah, MPI and firewalls don't mix well, and I believe Mavericks included a
change to harden the firewall due to increased attacks on Macs. You could
explore adding a rule that allows loopback across any port, but I suspect
your corporate IT might not like that much openness.
I'll write another OOB
I’ve been able to find out a little more information. The problem persists
regardless of which network I am connected to. I’ve tried our corporate
ethernet network, wifi network, a local hotel wifi network, my home network.
The problem persists over all network connections.
I tried turning o
Ralph --
Quick question: ORTE should be using local named sockets for connections to the
orted, right?
I guess what I'm asking is: if there's a
single-server-only-and-it-happens-to-be-the-local-server job, shouldn't it only
be using local named sockets, not IP sockets?
On Dec 3, 2013, at 8:
Best guess I can offer is that they are blocking loopback on those networks
- i.e., they are configured such that you can use them to connect to a
remote machine, but not to a process on your local machine. I'll take a
look at the connection logic and see if I can get it to failover to the
loopback
I disconnected for our corporate network (ethernet connection) and tried
running again: same result, it stalls.
Then, I also disconnected from our local wifi network and tried running again:
it worked!
bash-4.2$ mpirun -np 2 --mca btl sm,self hello_c
Hello, world, I am 0 of 2, (Open MPI v1.7.
Hmmm...are you connected to a network, or at least have a network active,
when you do this? It looks a little like the system is trying to open a
port between the process and mpirun, but is failing to do so.
On Tue, Dec 3, 2013 at 4:51 AM, Meredith, Karl
wrote:
> Using openmpi-1.7.4, no macport
Using openmpi-1.7.4, no macports, only apple compilers/tools:
mpirun -np 2 --mca btl sm,self hello_c
This hangs, also in MPI_Init().
Here’s the back trace from the debugger:
bash-4.2$ lldb -p 4517
Attaching to process with:
process attach -p 4517
Process 4517 stopped
Executable module set t
Karl --
Can you force the use of just the shared memory transport -- i.e., disable the
TCP BTL? For example:
mpirun -np 2 --mca btl sm,self hello_c
If that also hangs, can you attach a debugger and see *where* it is hanging
inside MPI_Init()? (In OMPI, MPI::Init() simply invokes MPI_Init
/opt/trunk/apple-only/bin/ompi_info --param oob tcp --level 9
MCA oob: parameter "oob_tcp_verbose" (current value: "0", data
source: default, level: 9 dev/all, type: int)
Verbose level for the OOB tcp component
MCA oob: parameter "oob_tcp
.3-noenv/lib/libopen-pal.6.dylib
>>>>> (compatibility version 7.0.0, current version 7.0.0)
>>>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>>>>> 1197.1.1)
>>>>> /usr/lib/libc++.1.dylib (compatibility versio
it is using the correct g++
>>>>
>>>> $ )which g++
>>>> /opt/local/bin/g++
>>>>
>>>>
>>>> $ )echo $PATH
>>>> /Users/meredithk/tools/openmpi/bin:/opt/local/bin:/opt/local/sbin:/Users/meredithk/tools/bin:/Users/meredit
l64Gcc46DPOpt/bin:/Users/meredithk/OpenFOAM/site/2.2.x/platforms/darwinIntel64Gcc46DPOpt/bin:/Users/meredithk/OpenFOAM/OpenFOAM-2.2.x/platforms/darwinIntel64Gcc46DPOpt/bin:/Users/meredithk/OpenFOAM/OpenFOAM-2.2.x/bin:/Users/meredithk/OpenFOAM/OpenFOAM-2.2.x/wmake:/Developer/usr/bin:/usr/bin:/
sr/bin:/bin:/usr/sbin:/sbin
>>
>>
>> $ )g++ --version
>> g++ (MacPorts gcc46 4.6.4_3) 4.6.4
>>
>>
>> Karl
>>
>>
>>
>> On Nov 27, 2013, at 3:23 AM, Iliev, Hristo
>> mailto:il...@rz.rwth-aachen.de><mailto:il...@rz.rwth-aache
t;
> The Xcode command-line tools provide a g++ command that is effectively
> clang++. Since mpic++ invokes g++ without the full path to it, it might pick
> the wrong g++. Make sure that /opt/local/bin is the first item in your
> $PATH.
>
> Hristo
>
> --
> Hristo Ilie
Aachen
Seffenter Weg 23, D-52074 Aachen (Germany)
-Original Message-
From: users [mailto:users-boun...@open-mpi.org] On Behalf Of Meredith,
Karl
Sent: Tuesday, November 26, 2013 9:33 PM
To: Open MPI Users
Subject: Re: [OMPI users] open-mpi on Mac OS 10.9 (Mavericks)
Here are the results of those two c
users [mailto:users-boun...@open-mpi.org] On Behalf Of Meredith,
Karl
Sent: Tuesday, November 26, 2013 9:33 PM
To: Open MPI Users
Subject: Re: [OMPI users] open-mpi on Mac OS 10.9 (Mavericks)
Here are the results of those two commands:
$ )mpic++ -show
g++ -I/Users/meredithk/tools/openmpi/include -
L/Users/mer
ent: Tuesday, November 26, 2013 9:33 PM
> To: Open MPI Users
> Subject: Re: [OMPI users] open-mpi on Mac OS 10.9 (Mavericks)
>
> Here are the results of those two commands:
>
> $ )mpic++ -show
> g++ -I/Users/meredithk/tools/openmpi/include -
> L/Users/meredithk/tools/openmpi/lib
Here are the results of those two commands:
$ )mpic++ -show
g++ -I/Users/meredithk/tools/openmpi/include
-L/Users/meredithk/tools/openmpi/lib -lmpi_cxx -lmpi -lm
$ )otool -L /Users/meredithk/tools/openmpi/lib/libmpi_cxx.dylib
/Users/meredithk/tools/openmpi/lib/libmpi_cxx.dylib:
/Users/me
Karl,
What does “mpic++ -show” returns ? It is possible that you are
compiling/linking with “c++”, which will defaults to clang++, while you
compiled OpenMPI with g++.
Since libstdc++ and libc++ have incompatible ABI, that might be why you are
getting a wrong behavior.
Also, it could be worthwhi
I do have DYLD_LIBRARY_PATH set as well, and I get the same problem:
DYLD_LIBRARY_PATH=/Users/meredithk/tools/openmpi/lib
Here’s the directory listing of /Users/meredithk/tools/openmpi/lib
$ )ls -1
libmca_common_sm.3.dylib*
libmca_common_sm.dylib@
libmca_common_sm.la*
libmpi.1.dylib*
libmpi.dyli
Am 25.11.2013 um 14:25 schrieb Meredith, Karl:
> I do have these two environment variables set:
>
> LD_LIBRARY_PATH=/Users/meredithk/tools/openmpi/lib
On a Mac it should DYLD_LIBRARY_PATH - and there are *.dylib files in your
/Users/meredithk/tools/openmpi/lib?
-- Reuti
> PATH=/Users/meredit
I do have these two environment variables set:
LD_LIBRARY_PATH=/Users/meredithk/tools/openmpi/lib
PATH=/Users/meredithk/tools/openmpi/bin
Running mpirun seems to work fine with a simple command, like hostname:
$ )mpirun -n 2 hostname
meredithk-mac.corp.fmglobal.com
meredithk-mac.corp.fmglobal.co
Strange - I run on Mavericks now without problem. Can you run "mpirun -n 1
hostname"?
You also might want to check your PATH and LD_LIBRARY_PATH to ensure you have
the prefix where you installed OMPI 1.6.5 at the front. Mac distributes a very
old version of OMPI with its software and you don't
I recently upgraded my 2013 Macbook Pro (Retina display) from 10.8 to 10.9. I
downloaded and installed openmpi-1.6.5 and compiled it with gcc 4.8 (gcc
installed from macports).
openmpi compiled and installed without error.
However, when I try to run any of the example test cases, the code get
26 matches
Mail list logo
