2009/4/9 <users-request@open-mpi.org>

Send users mailing list submissions to
users@open-mpi.org

To subscribe or unsubscribe via the World Wide Web, visit
http://www.open-mpi.org/mailman/listinfo.cgi/users
or, via email, send a message with subject or body 'help' to
users-request@open-mpi.org

You can reach the person managing the list at
users-owner@open-mpi.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."

Today's Topics:

1. mpirun self,sm (Robert Kubrick)
2. Re: mpirun self,sm (Ralph Castain)
3. shared libraries issue compiling 1.3.1/intel 10.1.022
(Francesco Pietra)

----------------------------------------------------------------------

Message: 1
Date: Thu, 9 Apr 2009 00:15:03 -0400
From: Robert Kubrick <robertkubrick@gmail.com>
Subject: [OMPI users] mpirun self,sm
To: Open MPI Users <users@open-mpi.org>
Message-ID: <99AB3654-DD6A-4E96-94AC-B741073821ED@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

How is this possible?

dx:~> mpirun -v -np 2 --mca btl self,sm --host dx,sx hostname
dx
sx

dx:~> netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-
OVR Flg
eth0 1500 0 998755 0 0 0 1070323 0
0 0 BMRU
eth1 1500 0 85352 0 0 0 379993 0
0 0 BMRU
ib0 65520 0 204 0 0 0 155 0
5 0 BMRU
lo 16436 0 1648874 0 0 0 1648874 0
0 0 LRU

I want to force an error with the first command above to make sure
that my btl parameters are used correctly, but it looks like ompi
runs hostname on the remote machine regardless.

------------------------------

Message: 2
Date: Thu, 9 Apr 2009 02:16:08 -0600
From: Ralph Castain <rhc@lanl.gov>
Subject: Re: [OMPI users] mpirun self,sm
To: Open MPI Users <users@open-mpi.org>
Message-ID: <FF3FCDB6-3E23-41F6-88BC-7D4F327E40DC@lanl.gov>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

hostname never calls MPI_Init, and therefore never initializes the BTL
subsystem. Therefore, hostname will always run correctly.

mpirun is not an MPI process, nor are the daemons used by OMPI to
launch the MPI job. Thus, they also do not call MPI_Init, and
therefore do not see the BTL subsystem.

So this example will run just fine. You need to run an MPI application
to cause it to fail.

Ralph

On Apr 8, 2009, at 10:15 PM, Robert Kubrick wrote:

> How is this possible?
>
> dx:~> mpirun -v -np 2 --mca btl self,sm --host dx,sx hostname
> dx
> sx
>
> dx:~> netstat -i
> Kernel Interface table
> Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP
> TX-OVR Flg
> eth0 1500 0 998755 0 0 0 1070323 0
> 0 0 BMRU
> eth1 1500 0 85352 0 0 0 379993 0
> 0 0 BMRU
> ib0 65520 0 204 0 0 0 155 0
> 5 0 BMRU
> lo 16436 0 1648874 0 0 0 1648874 0
> 0 0 LRU
>
> I want to force an error with the first command above to make sure
> that my btl parameters are used correctly, but it looks like ompi
> runs hostname on the remote machine regardless.
> _______________________________________________
> users mailing list
> users@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

------------------------------

Message: 3
Date: Thu, 9 Apr 2009 17:31:16 +0200
From: Francesco Pietra <chiendarret@gmail.com>
Subject: [OMPI users] shared libraries issue compiling 1.3.1/intel
10.1.022
To: Open MPI Users <users@open-mpi.org>
Message-ID:
<b87c422a0904090831q56a98e67w5000c90a94bf8a37@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi:
As failure to find "limits.h" in my attempted compilations of Amber of
th fast few days (amd64 lenny, openmpi 1.3.1, intel compilers
10.1.015) is probably (or I hope so) a bug of the version used of
intel compilers (I made with debian the same observations reported
for gentoo, http://software.intel.com/en-us/forums/intel-c-compiler/topic/59886/).

I made a deb package of 10.1.022, icc and ifort.

./configure CC icc, CXX icp, F77 and FC ifort --with-libnuma=/usr (not
/usr/lib so that the numa.h issue is not raised), "make clean", and
"mak install" gave no error signals. However, the compilation tests in
the examples did not pass and I really don't understand why.

The error, with both connectivity_c and hello_c (I was operating on
the parallel computer deb64 directly and have access to everything
there) was failure to find a shared library, libimf.so

# dpkg --search libimf.so
/opt/intel/fce/10.1.022/lib/libimf.so (the same for cce)

which path seems to be correctly sourced by iccvars.sh and
ifortvars.sh (incidentally, both files are -rw-r--r-- root root;
correct that non executable?)

echo $LD_LIBRARY_PATH
returned, inter alia,
/opt/intel/mkl/10.1.2.024/lib/em64t:/opt/intel/mkl/10.1.2.024/lib/em64t:/opt/intel/cce/10.1.022/lib:/opt/intel/fce/10.1.022/lib
(why twice the mkl?)

I surely miss to understand something fundamental. Hope other eyes see better

A kind person elsewhere suggested me on passing "The use of -rpath
during linking is highly recommended as opposed to setting
LD_LIBRARY_PATH at run time, not the least because it hardcodes the
paths to the "right" library files in the executables themselves"
Should this be relevant to the present issue, where to learn about
-rpath linking?

thanks
francesco pietra

------------------------------

_______________________________________________
users mailing list
users@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users

End of users Digest, Vol 1197, Issue 1
**************************************