Re: [OMPI users] unknown interface on openmpi-1.8.2a1r31742

[Siegmar Gross]

Hi,

> This bug should be fixed in tonight's tarball, BTW.
...
> > It is an unrelated bug introduced by a different commit -
> > causing mpirun to segfault upon termination. The fact that
> > you got the hostname to run indicates that this original
> > fix works, so at least we know the connection logic is now okay.

tyr fd1026 107 ompi_info | grep "MPI:"
Open MPI: 1.9a1r31784
tyr fd1026 108 mpiexec -np 3 --host tyr,sunpc1,linpc1 hostname
tyr.informatik.hs-fulda.de
linpc1
sunpc1
tyr fd1026 109 

Perfect! Thank you very much for your help. Tonight the current
version will be mirrored to my other machines, so that I can do
some more tests next week.


tyr fd1026 103 ompi_info | grep "MPI:"
Open MPI: 1.8.2a1r31785
tyr fd1026 104 mpiexec -np 3 --host tyr,sunpc1,linpc1 hostname
[tyr.informatik.hs-fulda.de:21100] [[62538,0],0] CONNECTION
  REQUEST ON UNKNOWN INTERFACE
[tyr.informatik.hs-fulda.de:21100] [[62538,0],0] CONNECTION
  REQUEST ON UNKNOWN INTERFACE
^CKilled by signal 2.
Killed by signal 2.
tyr fd1026 105 

Can you fix the connection logic for 1.8.2 as well? Thank you
very much for your help in advance.


Kind regards

Siegmar

Re: [OMPI users] unknown interface on openmpi-1.8.2a1r31742

[Ralph Castain]

Done - will be in nightly 1.8.2 tarball generated later today.


On May 16, 2014, at 2:57 AM, Siegmar Gross 
 wrote:

> Hi,
> 
>> This bug should be fixed in tonight's tarball, BTW.
> ...
>>> It is an unrelated bug introduced by a different commit -
>>> causing mpirun to segfault upon termination. The fact that
>>> you got the hostname to run indicates that this original
>>> fix works, so at least we know the connection logic is now okay.
> 
> tyr fd1026 107 ompi_info | grep "MPI:"
>Open MPI: 1.9a1r31784
> tyr fd1026 108 mpiexec -np 3 --host tyr,sunpc1,linpc1 hostname
> tyr.informatik.hs-fulda.de
> linpc1
> sunpc1
> tyr fd1026 109 
> 
> Perfect! Thank you very much for your help. Tonight the current
> version will be mirrored to my other machines, so that I can do
> some more tests next week.
> 
> 
> tyr fd1026 103 ompi_info | grep "MPI:"
>Open MPI: 1.8.2a1r31785
> tyr fd1026 104 mpiexec -np 3 --host tyr,sunpc1,linpc1 hostname
> [tyr.informatik.hs-fulda.de:21100] [[62538,0],0] CONNECTION
>  REQUEST ON UNKNOWN INTERFACE
> [tyr.informatik.hs-fulda.de:21100] [[62538,0],0] CONNECTION
>  REQUEST ON UNKNOWN INTERFACE
> ^CKilled by signal 2.
> Killed by signal 2.
> tyr fd1026 105 
> 
> Can you fix the connection logic for 1.8.2 as well? Thank you
> very much for your help in advance.
> 
> 
> Kind regards
> 
> Siegmar
> 
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

Re: [OMPI users] Question about scheduler support

[Jeff Squyres (jsquyres)]

On May 15, 2014, at 8:00 PM, Fabricio Cannini  wrote:

>> Nobody is disagreeing that one could find a way to make CMake work - all we 
>> are saying is that (a) CMake has issues too, just like autotools, and (b) we 
>> have yet to see a compelling reason to undertake the transition...which 
>> would have to be a *very* compelling one.
> 
> I was simply agreeing with Maxime about why it could work. ;)
> 
> But if you and the other devels are fine with it, i'm fine too.

FWIW, simply for my own curiosity's sake, if someone could confirm deny whether 
cmake:

1. Supports the following compiler suites: GNU (that's a given, I assume), 
Clang, OS X native (which is variants of GNU and Clang), Absoft, PGI, Intel, 
Cray, HP-UX, Oracle Solaris (Linux and Solaris), Tru64, Microsoft Visual, IBM 
BlueGene (I think that's gcc, but am not entirely sure).  (some of these matter 
mainly to hwloc, not necessarily OMPI)

2. Bootstrap a tarball such that an end user does not need to have cmake 
installed.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI users] bug in MPI_File_set_view?

[CANELA-XANDRI Oriol]

This option seems that fix the problem!

Oriol


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-Original Message-
From: users [mailto:users-boun...@open-mpi.org] On Behalf Of Edgar Gabriel
Sent: 15 May 2014 14:33
To: Open MPI Users
Subject: Re: [OMPI users] bug in MPI_File_set_view?

could you try just for curiosity to force to use OMPIO? e.g.
mpirun --mca io ompio 

Thanks
Edgar

On 5/15/2014 3:56 AM, CANELA-XANDRI Oriol wrote:
> Hi, I installed and tried with version 1.8.1 but it also fails. I see the 
> error when there are some processes without any matrix block. It's not a 
> common situation, but this makes me feel unsure about I am not doing 
> something wrong.  The error I get is:
> 
> *** Error in `./binary': free(): invalid size: 0x00a34c00 *** 
> [oriol-VirtualBox:13975] *** Process received signal *** 
> [oriol-VirtualBox:13975] Signal: Aborted (6) [oriol-VirtualBox:13975] 
> Signal code:  (-6) [oriol-VirtualBox:13969] *** Process received 
> signal *** [oriol-VirtualBox:13969] Signal: Aborted (6) 
> [oriol-VirtualBox:13969] Signal code:  (-6) === Backtrace: 
> = /lib/x86_64-linux-gnu/libc.so.6(+0x80996)[0x7f5844a8d996]
> [oriol-VirtualBox:13969] [ 0] 
> /lib/x86_64-linux-gnu/libc.so.6(+0x36ff0)[0x7f06a50a7ff0]
> [oriol-VirtualBox:13969] [ 1] 
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f06a50a7f77]
> [oriol-VirtualBox:13969] [ 2] 
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f06a50ab5e8]
> [oriol-VirtualBox:13969] [ 3] 
> /lib/x86_64-linux-gnu/libc.so.6(+0x744fb)[0x7f06a50e54fb]
> [oriol-VirtualBox:13969] [ 4] 
> /lib/x86_64-linux-gnu/libc.so.6(+0x80996)[0x7f06a50f1996]
> [oriol-VirtualBox:13969] [ 5] 
> /usr/local/lib/openmpi/mca_io_romio.so(ADIOI_Delete_flattened+0x62)[0x
> 7f0691e12c02] [oriol-VirtualBox:13969] [ 6] 
> /usr/local/lib/openmpi/mca_io_romio.so(ADIO_Close+0x1f9)[0x7f0691df718
> 9] [oriol-VirtualBox:13969] [ 7] 
> /usr/local/lib/openmpi/mca_io_romio.so(mca_io_romio_dist_MPI_File_clos
> e+0xe8)[0x7f0691de9dd8] [oriol-VirtualBox:13969] [ 8] 
> /usr/local/lib/libmpi.so.1(+0x3a2c6)[0x7f06a5ea02c6]
> [oriol-VirtualBox:13969] [ 9] 
> /usr/local/lib/libmpi.so.1(ompi_file_close+0x41)[0x7f06a5ea0811]
> [oriol-VirtualBox:13969] [10] 
> /usr/local/lib/libmpi.so.1(PMPI_File_close+0x78)[0x7f06a5edc118]
> [oriol-VirtualBox:13969] [11] ./binary[0x42099e] 
> [oriol-VirtualBox:13969] [12] ./binary[0x48ed86] 
> [oriol-VirtualBox:13969] [13] ./binary[0x40e49f] 
> [oriol-VirtualBox:13969] [14] 
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f06a5092de5
> ] [oriol-VirtualBox:13969] [15] ./binary[0x40d679] 
> [oriol-VirtualBox:13969] *** End of error message *** 
> [oriol-VirtualBox:13975] [ 0] 
> /lib/x86_64-linux-gnu/libc.so.6(+0x36ff0)[0x7f1857201ff0]
> [oriol-VirtualBox:13975] [ 1] 
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f1857201f77]
> [oriol-VirtualBox:13975] [ 2] 
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f18572055e8]
> [oriol-VirtualBox:13975] [ 3] 
> /lib/x86_64-linux-gnu/libc.so.6(+0x744fb)[0x7f185723f4fb]
> [oriol-VirtualBox:13975] [ 4] 
> /lib/x86_64-linux-gnu/libc.so.6(+0x80996)[0x7f185724b996]
> [oriol-VirtualBox:13975] [ 5] 
> /usr/local/lib/openmpi/mca_io_romio.so(ADIOI_Delete_flattened+0x62)[0x
> 7f18459d2c02] [oriol-VirtualBox:13975] [ 6] 
> /usr/local/lib/openmpi/mca_io_romio.so(ADIO_Close+0x1f9)[0x7f18459b718
> 9] [oriol-VirtualBox:13975] [ 7] 
> /usr/local/lib/openmpi/mca_io_romio.so(mca_io_romio_dist_MPI_File_clos
> e+0xe8)[0x7f18459a9dd8] [oriol-VirtualBox:13975] [ 8] 
> /usr/local/lib/libmpi.so.1(+0x3a2c6)[0x7f1857ffa2c6]
> [oriol-VirtualBox:13975] [ 9] 
> /usr/local/lib/libmpi.so.1(ompi_file_close+0x41)[0x7f1857ffa811]
> [oriol-VirtualBox:13975] [10] 
> /usr/local/lib/libmpi.so.1(PMPI_File_close+0x78)[0x7f1858036118]
> [oriol-VirtualBox:13975] [11] ./binary[0x42099e] 
> [oriol-VirtualBox:13975] [12] ./binary[0x48ed86] 
> [oriol-VirtualBox:13975] [13] ./binary[0x40e49f] 
> [oriol-VirtualBox:13975] [14] 
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f18571ecde5
> ] [oriol-VirtualBox:13975] [15] ./binary[0x40d679] 
> [oriol-VirtualBox:13975] *** End of error message *** 
> [oriol-VirtualBox:13972] *** Process received signal *** 
> [oriol-VirtualBox:13972] Signal: Aborted (6) [oriol-VirtualBox:13972] 
> Signal code:  (-6) [oriol-VirtualBox:13972] [ 0] 
> /lib/x86_64-linux-gnu/libc.so.6(+0x36ff0)[0x7f5844a43ff0]
> [oriol-VirtualBox:13972] [ 1] 
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f5844a43f77]
> [oriol-VirtualBox:13972] [ 2] 
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f5844a475e8]
> [oriol-VirtualBox:13972] [ 3] 
> /lib/x86_64-linux-gnu/libc.so.6(+0x744fb)[0x7f5844a814fb]
> [oriol-VirtualBox:13972] [ 4] 
> /lib/x86_64-linux-gnu/libc.so.6(+0x80996)[0x7f5844a8d996]
> [oriol-VirtualBox:13972] [ 5] 
> /usr/local/lib/openmpi/mca_io_romio.so(ADIOI_Delete_flattened+0x62)[0x
> 7f58315f2c02] [oriol-VirtualBox:

Re: [OMPI users] Question about scheduler support

[Maxime Boissonneault]

Le 2014-05-16 09:06, Jeff Squyres (jsquyres) a écrit :

On May 15, 2014, at 8:00 PM, Fabricio Cannini  wrote:


Nobody is disagreeing that one could find a way to make CMake work - all we are 
saying is that (a) CMake has issues too, just like autotools, and (b) we have 
yet to see a compelling reason to undertake the transition...which would have 
to be a *very* compelling one.

I was simply agreeing with Maxime about why it could work. ;)

But if you and the other devels are fine with it, i'm fine too.

FWIW, simply for my own curiosity's sake, if someone could confirm deny whether 
cmake:

1. Supports the following compiler suites: GNU (that's a given, I assume), 
Clang, OS X native (which is variants of GNU and Clang), Absoft, PGI, Intel, 
Cray, HP-UX, Oracle Solaris (Linux and Solaris), Tru64, Microsoft Visual, IBM 
BlueGene (I think that's gcc, but am not entirely sure).  (some of these matter 
mainly to hwloc, not necessarily OMPI)
I have built projects with CMake using GNU, Intel, PGI, OS X native. 
CMake claims to make MSV projects, so I'm assuming MS Visual works. I 
can't say about the others.

2. Bootstrap a tarball such that an end user does not need to have cmake 
installed.

That, I have no clue, but they do have a page about bootstrapping cmake 
itself

http://www.cmake.org/cmake/help/install.html
I am not sure if this is what you mean.

If there is no existing CMake installation, a bootstrap script is provided:

   ./bootstrap
make
make install

(Note: the make install step is optional, cmake will run from the build 
directory.)


According to this, you could have a tarball including CMake and instruct 
the users to run some variant of (or make your own bootstrap script 
including this)

 ./bootstrap && make && ./cmake . && make && make install

Now that I think about it, OpenFOAM uses CMake and bootstraps it if it 
is not install, so it is certainly possible.



Maxime

[OMPI users] can't disable infiniband communication

[Sylvain Huet]

Dear all,

I am reinstalling a cluster where nodes are connected by
- 1 Gb ethernet interfaces
- 40 Gb infinband adapters
I installed OFED 3.12 on CentOS 6.5

I would like to be able to tell mpirun to use either the Gb ethernet
interfaces or the infinband adapters.

But, when I launch osu_bw with the following commands I always obtain
bandwidths of the infinibands links
(hostether is a file containing the IPs of the ethernet interfaces
IPs of ib adapters: 192.168.1.2,192.168.1.3
IPs of ethernet adapters: 192.168.70.12,192.168.70.13 )

mpirun --map-by node --mca btl ^openib  --hostfile ./hostether  -np 2 
./osu_bw


mpirun --map-by node --mca btl_tcp_if_include eth0,eth1 --mca btl 
tcp,self --hostfile ./hostether  -np 2 ./osu_bw


mpirun --map-by node --mca btl_tcp_if_exclude ib0,ib1 --mca btl tcp,self 
--hostfile ./hostether  -np 2 ./osu_bw


mpirun --map-by node --mca btl_tcp_if_exclude 
192.168.1.2,192.168.1.3,127.0.0.1/8,sppp --mca btl tcp,self --host 
192.168.70.12,192.168.70.13 -np 2 ./osu_bw



All the previous commands lead to the following results with
either Open MPI 1.5.5, 1.7.5 or 1.8.1:

# OSU MPI Bandwidth Test (Version 2.3)
# Size  Bandwidth (MB/s)
1   2.14
... ...
2097152 3015.64
4194304 3017.91


If I stop openibd I logically obtain these results:

# OSU MPI Bandwidth Test (Version 2.3)
# Size  Bandwidth (MB/s)
1   0.19
... ...
2097152 117.63
4194304 117.66


Could someone give me some idea to investigate?

PS. I previouslly used this cluster with older versions
of CentOS and OFED and I was able to tell mpirun not to use
the infiniband adapters.


Best regards.

Re: [OMPI users] Question about scheduler support

[Fabricio Cannini]

Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:

On May 15, 2014, at 8:00 PM, Fabricio Cannini 
wrote:


Nobody is disagreeing that one could find a way to make CMake
work - all we are saying is that (a) CMake has issues too, just
like autotools, and (b) we have yet to see a compelling reason to
undertake the transition...which would have to be a *very*
compelling one.


I was simply agreeing with Maxime about why it could work. ;)

But if you and the other devels are fine with it, i'm fine too.


FWIW, simply for my own curiosity's sake, if someone could confirm
deny whether cmake:

1. Supports the following compiler suites: GNU (that's a given, I
assume), Clang, OS X native (which is variants of GNU and Clang),
Absoft, PGI, Intel, Cray, HP-UX, Oracle Solaris (Linux and Solaris),
 Tru64, Microsoft Visual, IBM BlueGene (I think that's gcc, but am
not entirely sure).  (some of these matter mainly to hwloc, not
necessarily OMPI)


Not 100% confirmed, but this is good evidence that cmake does indeed 
supports all these suites. See the file list:


http://fr2.rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/cmake-2.6.4-5.el6.x86_64.html

http://fr2.rpmfind.net//linux/RPM/dag/redhat/el6/x86_64/extras/cmake-2.8.8-1.el6.rfx.x86_64.html

http://fr2.rpmfind.net//linux/RPM/opensuse/factory/aarch64/aarch64/cmake-3.0.0~rc4-2.1.aarch64.html


2. Bootstrap a tarball such that an end user does not need to have
cmake installed.


What do you mean by 'bootstrapping a tarball' ?

Re: [OMPI users] Question about scheduler support

[Ralph Castain]

On May 16, 2014, at 1:03 PM, Fabricio Cannini  wrote:

> Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:
>> On May 15, 2014, at 8:00 PM, Fabricio Cannini 
>> wrote:
>> 
 Nobody is disagreeing that one could find a way to make CMake
 work - all we are saying is that (a) CMake has issues too, just
 like autotools, and (b) we have yet to see a compelling reason to
 undertake the transition...which would have to be a *very*
 compelling one.
>>> 
>>> I was simply agreeing with Maxime about why it could work. ;)
>>> 
>>> But if you and the other devels are fine with it, i'm fine too.
>> 
>> FWIW, simply for my own curiosity's sake, if someone could confirm
>> deny whether cmake:
>> 
>> 1. Supports the following compiler suites: GNU (that's a given, I
>> assume), Clang, OS X native (which is variants of GNU and Clang),
>> Absoft, PGI, Intel, Cray, HP-UX, Oracle Solaris (Linux and Solaris),
>> Tru64, Microsoft Visual, IBM BlueGene (I think that's gcc, but am
>> not entirely sure).  (some of these matter mainly to hwloc, not
>> necessarily OMPI)
> 
> Not 100% confirmed, but this is good evidence that cmake does indeed supports 
> all these suites. See the file list:
> 
> http://fr2.rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/cmake-2.6.4-5.el6.x86_64.html
> 
> http://fr2.rpmfind.net//linux/RPM/dag/redhat/el6/x86_64/extras/cmake-2.8.8-1.el6.rfx.x86_64.html
> 
> http://fr2.rpmfind.net//linux/RPM/opensuse/factory/aarch64/aarch64/cmake-3.0.0~rc4-2.1.aarch64.html
> 
>> 2. Bootstrap a tarball such that an end user does not need to have
>> cmake installed.
> 
> What do you mean by 'bootstrapping a tarball' ?

If someone doesn't have cmake installed and downloads a tarball that was built 
from a CMake-based project, can they configure/build that tarball? Or do they 
have to install cmake first?

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

Re: [OMPI users] Question about scheduler support

[Hjelm, Nathan T]

+1 the bootstrapping issue is 50% of the reason I will never use CMake for any 
production code.

vygr:~ hjelmn$ type -p cmake
vygr:~ hjelmn$ 

Nada, zilch, nothing on standard OS X install. I do not want to put an extra 
requirement on my users. Nor do I want something as simple-minded as CMake. 
autotools works great for me.

-Nathan


From: users [users-boun...@open-mpi.org] on behalf of Ralph Castain 
[r...@open-mpi.org]
Sent: Friday, May 16, 2014 2:07 PM
To: Open MPI Users
Subject: Re: [OMPI users] Question about scheduler support

On May 16, 2014, at 1:03 PM, Fabricio Cannini 
mailto:fcann...@gmail.com>> wrote:

Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:
On May 15, 2014, at 8:00 PM, Fabricio Cannini 
mailto:fcann...@gmail.com>>
wrote:

Nobody is disagreeing that one could find a way to make CMake
work - all we are saying is that (a) CMake has issues too, just
like autotools, and (b) we have yet to see a compelling reason to
undertake the transition...which would have to be a *very*
compelling one.

I was simply agreeing with Maxime about why it could work. ;)

But if you and the other devels are fine with it, i'm fine too.

FWIW, simply for my own curiosity's sake, if someone could confirm
deny whether cmake:

1. Supports the following compiler suites: GNU (that's a given, I
assume), Clang, OS X native (which is variants of GNU and Clang),
Absoft, PGI, Intel, Cray, HP-UX, Oracle Solaris (Linux and Solaris),
Tru64, Microsoft Visual, IBM BlueGene (I think that's gcc, but am
not entirely sure).  (some of these matter mainly to hwloc, not
necessarily OMPI)

Not 100% confirmed, but this is good evidence that cmake does indeed supports 
all these suites. See the file list:

http://fr2.rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/cmake-2.6.4-5.el6.x86_64.html

http://fr2.rpmfind.net//linux/RPM/dag/redhat/el6/x86_64/extras/cmake-2.8.8-1.el6.rfx.x86_64.html

http://fr2.rpmfind.net//linux/RPM/opensuse/factory/aarch64/aarch64/cmake-3.0.0~rc4-2.1.aarch64.html

2. Bootstrap a tarball such that an end user does not need to have
cmake installed.

What do you mean by 'bootstrapping a tarball' ?

If someone doesn't have cmake installed and downloads a tarball that was built 
from a CMake-based project, can they configure/build that tarball? Or do they 
have to install cmake first?

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

Re: [OMPI users] Question about scheduler support

[Martin Siegert]

+1 even if cmake would make life easier for the developpers, you may
   want to consider those sysadmins/users who actually need to compile
   and install the software. And for those cmake is a nightmare. Everytime
   I run into a software package that uses cmake it makes me cringe.
   gromacs is the perfect example - it has become orders of magnitudes
   more complicated to compile just because it now uses cmake. I still
   have not succeeded cross compiling (compiling on a machine with a
   different processor than the code will later run on) gromacs. This was
   trivial before they switched to cmake.
   Another example: want to add RPATH to the executables/libraries?
   Just set LDFLAGS='-Wl,-rpath,/usr/local/xyz/lib64' with autotools.
   With cmake? Really complicated.

Please, just say no.

Cheers,
Martin

On Fri, May 16, 2014 at 08:33:15PM +, Hjelm, Nathan T wrote:
> +1 the bootstrapping issue is 50% of the reason I will never use CMake for 
> any production code.
> 
> vygr:~ hjelmn$ type -p cmake
> vygr:~ hjelmn$ 
> 
> Nada, zilch, nothing on standard OS X install. I do not want to put an extra 
> requirement on my users. Nor do I want something as simple-minded as CMake. 
> autotools works great for me.
> 
> -Nathan
> 
> 
> From: users [users-boun...@open-mpi.org] on behalf of Ralph Castain 
> [r...@open-mpi.org]
> Sent: Friday, May 16, 2014 2:07 PM
> To: Open MPI Users
> Subject: Re: [OMPI users] Question about scheduler support
> 
> On May 16, 2014, at 1:03 PM, Fabricio Cannini 
> mailto:fcann...@gmail.com>> wrote:
> 
> Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:
> On May 15, 2014, at 8:00 PM, Fabricio Cannini 
> mailto:fcann...@gmail.com>>
> wrote:
> 
> Nobody is disagreeing that one could find a way to make CMake
> work - all we are saying is that (a) CMake has issues too, just
> like autotools, and (b) we have yet to see a compelling reason to
> undertake the transition...which would have to be a *very*
> compelling one.
> 
> I was simply agreeing with Maxime about why it could work. ;)
> 
> But if you and the other devels are fine with it, i'm fine too.
> 
> FWIW, simply for my own curiosity's sake, if someone could confirm
> deny whether cmake:
> 
> 1. Supports the following compiler suites: GNU (that's a given, I
> assume), Clang, OS X native (which is variants of GNU and Clang),
> Absoft, PGI, Intel, Cray, HP-UX, Oracle Solaris (Linux and Solaris),
> Tru64, Microsoft Visual, IBM BlueGene (I think that's gcc, but am
> not entirely sure).  (some of these matter mainly to hwloc, not
> necessarily OMPI)
> 
> Not 100% confirmed, but this is good evidence that cmake does indeed supports 
> all these suites. See the file list:
> 
> http://fr2.rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/cmake-2.6.4-5.el6.x86_64.html
> 
> http://fr2.rpmfind.net//linux/RPM/dag/redhat/el6/x86_64/extras/cmake-2.8.8-1.el6.rfx.x86_64.html
> 
> http://fr2.rpmfind.net//linux/RPM/opensuse/factory/aarch64/aarch64/cmake-3.0.0~rc4-2.1.aarch64.html
> 
> 2. Bootstrap a tarball such that an end user does not need to have
> cmake installed.
> 
> What do you mean by 'bootstrapping a tarball' ?
> 
> If someone doesn't have cmake installed and downloads a tarball that was 
> built from a CMake-based project, can they configure/build that tarball? Or 
> do they have to install cmake first?

Re: [OMPI users] Question about scheduler support

[Fabricio Cannini]

Em 16-05-2014 17:07, Ralph Castain escreveu:

FWIW, simply for my own curiosity's sake, if someone could confirm
deny whether cmake:

1. Supports the following compiler suites: GNU (that's a given, I
assume), Clang, OS X native (which is variants of GNU and Clang),
Absoft, PGI, Intel, Cray, HP-UX, Oracle Solaris (Linux and Solaris),
Tru64, Microsoft Visual, IBM BlueGene (I think that's gcc, but am
not entirely sure).  (some of these matter mainly to hwloc, not
necessarily OMPI)


Not 100% confirmed, but this is good evidence that cmake does indeed
supports all these suites. See the file list:

http://fr2.rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/cmake-2.6.4-5.el6.x86_64.html

http://fr2.rpmfind.net//linux/RPM/dag/redhat/el6/x86_64/extras/cmake-2.8.8-1.el6.rfx.x86_64.html

http://fr2.rpmfind.net//linux/RPM/opensuse/factory/aarch64/aarch64/cmake-3.0.0~rc4-2.1.aarch64.html


2. Bootstrap a tarball such that an end user does not need to have
cmake installed.


What do you mean by 'bootstrapping a tarball' ?


If someone doesn't have cmake installed and downloads a tarball that was
built from a CMake-based project, can they configure/build that tarball?
Or do they have to install cmake first?


Ah, right. Yes, cmake must be installed to bootstrap the tarball.

Re: [OMPI users] Question about scheduler support (or is this about cmake now?)

[John Cary]

For cmake,

-DCMAKE_SHARED_LINKER_FLAGS:STRING=-Wl,-rpath,'$HDF5_SERSH_DIR/lib'
or
-DCMAKE_EXE_LINKER_FLAGS:STRING=-Wl,-rpath,'$HDF5_SERSH_DIR/lib'

I don't have a dog in this, but I will say that we have found supporting 
Windows

to be much easier with cmake.  If that is not an issue, then autotools is
is just fine too.  We do both and are happy with either.

Yes, one must build cmake to use it.  Does not seem to be a critical
issue to me if one wants to support Windows, as you have to install
something (e.g., cygwin) to use autotools.

We looked into cmake for openmpi a while ago, but only because we wondered
whether there was much interest in supporting Windows. There wasn't.

As to compiler support, we build our codes on all of

Clang, OS X native (which is variants of GNU and Clang),
PGI, Intel, Cray, Microsoft Visual, IBM BlueGene (xl).

Have not tried  Absoft, HP-UX, Oracle Solaris (Linux and Solaris), Tru64.
Only rarely are we seeing the last three OS's anymore.  No requests.
But I am confident cmake could do these.

..John






On 5/16/2014 3:00 PM, Martin Siegert wrote:

+1 even if cmake would make life easier for the developpers, you may
want to consider those sysadmins/users who actually need to compile
and install the software. And for those cmake is a nightmare. Everytime
I run into a software package that uses cmake it makes me cringe.
gromacs is the perfect example - it has become orders of magnitudes
more complicated to compile just because it now uses cmake. I still
have not succeeded cross compiling (compiling on a machine with a
different processor than the code will later run on) gromacs. This was
trivial before they switched to cmake.
Another example: want to add RPATH to the executables/libraries?
Just set LDFLAGS='-Wl,-rpath,/usr/local/xyz/lib64' with autotools.
With cmake? Really complicated.

Please, just say no.

Cheers,
Martin

On Fri, May 16, 2014 at 08:33:15PM +, Hjelm, Nathan T wrote:

+1 the bootstrapping issue is 50% of the reason I will never use CMake for any 
production code.

vygr:~ hjelmn$ type -p cmake
vygr:~ hjelmn$

Nada, zilch, nothing on standard OS X install. I do not want to put an extra 
requirement on my users. Nor do I want something as simple-minded as CMake. 
autotools works great for me.

-Nathan


From: users [users-boun...@open-mpi.org] on behalf of Ralph Castain 
[r...@open-mpi.org]
Sent: Friday, May 16, 2014 2:07 PM
To: Open MPI Users
Subject: Re: [OMPI users] Question about scheduler support

On May 16, 2014, at 1:03 PM, Fabricio Cannini 
mailto:fcann...@gmail.com>> wrote:

Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:
On May 15, 2014, at 8:00 PM, Fabricio Cannini 
mailto:fcann...@gmail.com>>
wrote:

Nobody is disagreeing that one could find a way to make CMake
work - all we are saying is that (a) CMake has issues too, just
like autotools, and (b) we have yet to see a compelling reason to
undertake the transition...which would have to be a *very*
compelling one.

I was simply agreeing with Maxime about why it could work. ;)

But if you and the other devels are fine with it, i'm fine too.

FWIW, simply for my own curiosity's sake, if someone could confirm
deny whether cmake:

1. Supports the following compiler suites: GNU (that's a given, I
assume), Clang, OS X native (which is variants of GNU and Clang),
Absoft, PGI, Intel, Cray, HP-UX, Oracle Solaris (Linux and Solaris),
Tru64, Microsoft Visual, IBM BlueGene (I think that's gcc, but am
not entirely sure).  (some of these matter mainly to hwloc, not
necessarily OMPI)

Not 100% confirmed, but this is good evidence that cmake does indeed supports 
all these suites. See the file list:

http://fr2.rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/cmake-2.6.4-5.el6.x86_64.html

http://fr2.rpmfind.net//linux/RPM/dag/redhat/el6/x86_64/extras/cmake-2.8.8-1.el6.rfx.x86_64.html

http://fr2.rpmfind.net//linux/RPM/opensuse/factory/aarch64/aarch64/cmake-3.0.0~rc4-2.1.aarch64.html

2. Bootstrap a tarball such that an end user does not need to have
cmake installed.

What do you mean by 'bootstrapping a tarball' ?

If someone doesn't have cmake installed and downloads a tarball that was built 
from a CMake-based project, can they configure/build that tarball? Or do they 
have to install cmake first?

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

[OMPI users] Enable PMI build

[Brock Palen]

We are looking at enabling the use of OpenMPI on our Xeon Phis, 

One comment, i'm not sure that most users will know that pmi means phi, 
  --with-pmi(=DIR)Build PMI support, optionally adding DIR to the
  search path (default: no)

how about:
  --with-pmi(=DIR)Build PMI support for the Xeon Phi/MIC, optionally 
adding DIR to the
  search path (default: no)


Second, digging in my mpss install I am not finding pmi.h or anything like that 
that searching the mailing list shows. We recently found that Intel made a lot 
of changes to the MPSS stack and this Phi stuff is very infantile at the moment 
so minimal (decent) documentation,  does anyone know what current package 
provides PMI  for the Xeon Phi?

Thanks!

Brock Palen
www.umich.edu/~brockp
CAEN Advanced Computing
XSEDE Campus Champion
bro...@umich.edu
(734)936-1985





signature.asc
Description: Message signed with OpenPGP using GPGMail

[OMPI users] openmpi configuration error?

[Ben Lash]

My cluster has just upgraded to a new version of MPI, and I'm using an old
one. It seems that I'm having trouble compiling due to the compiler wrapper
file moving (full error here: http://pastebin.com/EmwRvCd9)
"Cannot open configuration file
/opt/apps/openmpi/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt"

I've found the file on the cluster at
 /opt/apps/openmpi/retired/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt
How do I tell the old mpi wrapper where this file is?
I've already corrected one link to mpich ->
/opt/apps/openmpi/retired/1.4.4-intel/,
which is in the software I'm trying to recompile's lib folder
(/home/bl10/CMAQv5.0.1/lib/x86_64/ifort). Thanks for any ideas. I also
tried changing $pkgdatadir based on what I read here:
http://www.open-mpi.org/faq/?category=mpi-apps#default-wrapper-compiler-flags

Thanks.

--Ben L

Re: [OMPI users] Enable PMI build

[Hjelm, Nathan T]

PMI != phi. If you want to build for phi you will have to make two builds. One 
for the host and one for the phi.

Take a look in contrib/platform/lanl/darwin to get an idea of how to build for 
phi. The optimized-mic has most of what is needed to build a Phi version of 
Open MPI.

I usually run:

mkdir build-host ; cd build-host ; ../configure --prefix=path_to_host_build 
--with-platform=../contrib/platform/lanl/darwin/optimized ; make install
cd ../
mkdir build-pbi ; cd build-phi ; ../configure --prefix=path_to_phi_build 
--with-platform=..//contrib/platform/lanl/darwin/optimized-mic ; make install


I then modify the share/openmpi/mpicc-wrapper-data.txt to add a section for 
-mmic and have it point to the phi build. This is a bit complicated but it 
works well since mpicc -mmic with then use the phi libraries. I can give you a 
sample modified wrapper if you like.

-Nathan Hjelm
HPC-5, LANL

From: users [users-boun...@open-mpi.org] on behalf of Brock Palen 
[bro...@umich.edu]
Sent: Friday, May 16, 2014 3:31 PM
To: Open MPI Users
Subject: [OMPI users] Enable PMI build

We are looking at enabling the use of OpenMPI on our Xeon Phis,

One comment, i'm not sure that most users will know that pmi means phi,
  --with-pmi(=DIR)Build PMI support, optionally adding DIR to the
  search path (default: no)

how about:
  --with-pmi(=DIR)Build PMI support for the Xeon Phi/MIC, optionally 
adding DIR to the
  search path (default: no)


Second, digging in my mpss install I am not finding pmi.h or anything like that 
that searching the mailing list shows. We recently found that Intel made a lot 
of changes to the MPSS stack and this Phi stuff is very infantile at the moment 
so minimal (decent) documentation,  does anyone know what current package 
provides PMI  for the Xeon Phi?

Thanks!

Brock Palen
www.umich.edu/~brockp
CAEN Advanced Computing
XSEDE Campus Champion
bro...@umich.edu
(734)936-1985

Re: [OMPI users] Question about scheduler support (or is this about cmake now?)

[Elken, Tom]

Martin Siegert wrote:
> Just set LDFLAGS='-Wl,-rpath,/usr/local/xyz/lib64' with autotools.
> With cmake? Really complicated.

John Cary wrote:
> For cmake,
> 
> -DCMAKE_SHARED_LINKER_FLAGS:STRING=-Wl,-rpath,'$HDF5_SERSH_DIR/lib'
> or
> -DCMAKE_EXE_LINKER_FLAGS:STRING=-Wl,-rpath,'$HDF5_SERSH_DIR/lib'
[Tom] 
OK, so you verified the "really complicated" comment.

It seems clear to me that the OpenMPI developers are not going to switch to 
Cmake.
So why is this discussion continuing?

-Tom

> 
> I don't have a dog in this, but I will say that we have found supporting
> Windows
> to be much easier with cmake.  If that is not an issue, then autotools is
> is just fine too.  We do both and are happy with either.
> 
> Yes, one must build cmake to use it.  Does not seem to be a critical
> issue to me if one wants to support Windows, as you have to install
> something (e.g., cygwin) to use autotools.
> 
> We looked into cmake for openmpi a while ago, but only because we wondered
> whether there was much interest in supporting Windows. There wasn't.
> 
> As to compiler support, we build our codes on all of
> 
> Clang, OS X native (which is variants of GNU and Clang),
> PGI, Intel, Cray, Microsoft Visual, IBM BlueGene (xl).
> 
> Have not tried  Absoft, HP-UX, Oracle Solaris (Linux and Solaris), Tru64.
> Only rarely are we seeing the last three OS's anymore.  No requests.
> But I am confident cmake could do these.
> 
> ..John
> 
> 
> 
> 
> 
> 
> On 5/16/2014 3:00 PM, Martin Siegert wrote:
> > +1 even if cmake would make life easier for the developpers, you may
> > want to consider those sysadmins/users who actually need to compile
> > and install the software. And for those cmake is a nightmare. Everytime
> > I run into a software package that uses cmake it makes me cringe.
> > gromacs is the perfect example - it has become orders of magnitudes
> > more complicated to compile just because it now uses cmake. I still
> > have not succeeded cross compiling (compiling on a machine with a
> > different processor than the code will later run on) gromacs. This was
> > trivial before they switched to cmake.
> > Another example: want to add RPATH to the executables/libraries?
> > Just set LDFLAGS='-Wl,-rpath,/usr/local/xyz/lib64' with autotools.
> > With cmake? Really complicated.
> >
> > Please, just say no.
> >
> > Cheers,
> > Martin
> >
> > On Fri, May 16, 2014 at 08:33:15PM +, Hjelm, Nathan T wrote:
> >> +1 the bootstrapping issue is 50% of the reason I will never use CMake for
> any production code.
> >>
> >> vygr:~ hjelmn$ type -p cmake
> >> vygr:~ hjelmn$
> >>
> >> Nada, zilch, nothing on standard OS X install. I do not want to put an 
> >> extra
> requirement on my users. Nor do I want something as simple-minded as CMake.
> autotools works great for me.
> >>
> >> -Nathan
> >>
> >> 
> >> From: users [users-boun...@open-mpi.org] on behalf of Ralph Castain
> [r...@open-mpi.org]
> >> Sent: Friday, May 16, 2014 2:07 PM
> >> To: Open MPI Users
> >> Subject: Re: [OMPI users] Question about scheduler support
> >>
> >> On May 16, 2014, at 1:03 PM, Fabricio Cannini
> mailto:fcann...@gmail.com>> wrote:
> >>
> >> Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:
> >> On May 15, 2014, at 8:00 PM, Fabricio Cannini
> mailto:fcann...@gmail.com>>
> >> wrote:
> >>
> >> Nobody is disagreeing that one could find a way to make CMake
> >> work - all we are saying is that (a) CMake has issues too, just
> >> like autotools, and (b) we have yet to see a compelling reason to
> >> undertake the transition...which would have to be a *very*
> >> compelling one.
> >>
> >> I was simply agreeing with Maxime about why it could work. ;)
> >>
> >> But if you and the other devels are fine with it, i'm fine too.
> >>
> >> FWIW, simply for my own curiosity's sake, if someone could confirm
> >> deny whether cmake:
> >>
> >> 1. Supports the following compiler suites: GNU (that's a given, I
> >> assume), Clang, OS X native (which is variants of GNU and Clang),
> >> Absoft, PGI, Intel, Cray, HP-UX, Oracle Solaris (Linux and Solaris),
> >> Tru64, Microsoft Visual, IBM BlueGene (I think that's gcc, but am
> >> not entirely sure).  (some of these matter mainly to hwloc, not
> >> necessarily OMPI)
> >>
> >> Not 100% confirmed, but this is good evidence that cmake does indeed
> supports all these suites. See the file list:
> >>
> >> http://fr2.rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/cmake-
> 2.6.4-5.el6.x86_64.html
> >>
> >> http://fr2.rpmfind.net//linux/RPM/dag/redhat/el6/x86_64/extras/cmake-
> 2.8.8-1.el6.rfx.x86_64.html
> >>
> >>
> http://fr2.rpmfind.net//linux/RPM/opensuse/factory/aarch64/aarch64/cmake-
> 3.0.0~rc4-2.1.aarch64.html
> >>
> >> 2. Bootstrap a tarball such that an end user does not need to have
> >> cmake installed.
> >>
> >> What do you mean by 'bootstrapping a tarball' ?
> >>
> >> If someone doesn't have cmake installed and downlo

Re: [OMPI users] openmpi configuration error?

[Douglas L Reeder]

Ben,

You might want to use module (source forge) to manage paths to different mpi 
implementations. It is fairly easy to set up and very robust for this type of 
problem. You would remove contentious application paths from you standard PATH 
and then use module to switch them in and out as needed.

Doug Reeder
On May 16, 2014, at 3:39 PM, Ben Lash  wrote:

> My cluster has just upgraded to a new version of MPI, and I'm using an old 
> one. It seems that I'm having trouble compiling due to the compiler wrapper 
> file moving (full error here: http://pastebin.com/EmwRvCd9)
> "Cannot open configuration file 
> /opt/apps/openmpi/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt"
> 
> I've found the file on the cluster at  
> /opt/apps/openmpi/retired/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt
> How do I tell the old mpi wrapper where this file is?
> I've already corrected one link to mpich -> 
> /opt/apps/openmpi/retired/1.4.4-intel/, which is in the software I'm trying 
> to recompile's lib folder (/home/bl10/CMAQv5.0.1/lib/x86_64/ifort). Thanks 
> for any ideas. I also tried changing $pkgdatadir based on what I read here: 
> http://www.open-mpi.org/faq/?category=mpi-apps#default-wrapper-compiler-flags
> 
> Thanks. 
> 
> --Ben L
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

Re: [OMPI users] Question about scheduler support

[Gus Correa]

++1

The original issue was that OMPI builds support for slurm
and loadlevler by default, and this was not desirable (or desired).

That is a non-issue.
If you don't want slurm and loadleveler support,
just configure OMPI

--with-slurm=no --with-loadleveler=no

All other supported schedulers can be dismissed by similar configure 
flags, if one is strict about having a slim OMPI installation.
For those who love the minutiae, 'configure --help' will show all 
options, including those above,

and I am surprised that this was not noticed first place (and used)
by those complaining of the default support
to slurm and loadleveler on OMPI.

So, why the fuss if the solution is so simple?

I am happy with the way OMPI builds.
For me the main goal is to provide a reliable and flexible MPI build
to support parallel programs, not to fiddle with the build system.
Given the small number
of complaints about the OMPI build system on this list so far
(was there any before this one?),
I would guess most OMPI users also are happy with its build system.
We have GigE, Infiniband, and Torque: OMPI picks them up and
works perfectly with them.
We don't have Open-MX or Knem, but if we had, I would like them to be
discovered by OMPI and used.
As Bert Lance would say:
"If it ain't broke, don't fix it."
But not only it is not broken, it works like a charm.

Why switch to a different tool chain?
Is it wise, safe, widely available on the OMPI installed base, 
convenient to the final user?
Quite frankly this is the first time I see so much fuss about OMPI's 
build system.


Gus Correa

On 5/16/2014 3:00 PM, Martin Siegert wrote:

+1 even if cmake would make life easier for the developpers, you may
want to consider those sysadmins/users who actually need to compile
and install the software. And for those cmake is a nightmare.
Everytime
I run into a software package that uses cmake it makes me cringe.
gromacs is the perfect example - it has become orders of magnitudes
more complicated to compile just because it now uses cmake. I still
have not succeeded cross compiling (compiling on a machine with a
different processor than the code will later run on) gromacs. This
was
trivial before they switched to cmake.
Another example: want to add RPATH to the executables/libraries?
Just set LDFLAGS='-Wl,-rpath,/usr/local/xyz/lib64' with autotools.
With cmake? Really complicated.

Please, just say no.

Cheers,
Martin

On Fri, May 16, 2014 at 08:33:15PM +, Hjelm, Nathan T wrote:

+1 the bootstrapping issue is 50% of the reason I will never use
CMake for any production code.

vygr:~ hjelmn$ type -p cmake
vygr:~ hjelmn$

Nada, zilch, nothing on standard OS X install. I do not want to put
an extra requirement on my users. Nor do I want something as
simple-minded as CMake. autotools works great for me.

-Nathan


From: users [users-boun...@open-mpi.org] on behalf of Ralph Castain
[r...@open-mpi.org]
Sent: Friday, May 16, 2014 2:07 PM
To: Open MPI Users
Subject: Re: [OMPI users] Question about scheduler support

On May 16, 2014, at 1:03 PM, Fabricio Cannini
mailto:fcann...@gmail.com>> wrote:

Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:
On May 15, 2014, at 8:00 PM, Fabricio Cannini
mailto:fcann...@gmail.com>>
wrote:

Nobody is disagreeing that one could find a way to make CMake
work - all we are saying is that (a) CMake has issues too, just
like autotools, and (b) we have yet to see a compelling reason to
undertake the transition...which would have to be a *very*
compelling one.

I was simply agreeing with Maxime about why it could work. ;)

But if you and the other devels are fine with it, i'm fine too.

FWIW, simply for my own curiosity's sake, if someone could confirm
deny whether cmake:

1. Supports the following compiler suites: GNU (that's a given, I
assume), Clang, OS X native (which is variants of GNU and Clang),
Absoft, PGI, Intel, Cray, HP-UX, Oracle Solaris (Linux and Solaris),
Tru64, Microsoft Visual, IBM BlueGene (I think that's gcc, but am
not entirely sure).  (some of these matter mainly to hwloc, not
necessarily OMPI)

Not 100% confirmed, but this is good evidence that cmake does indeed
supports all these suites. See the file list:

http://fr2.rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/cmake-2.6.4-5.el6.x86_64.html


http://fr2.rpmfind.net//linux/RPM/dag/redhat/el6/x86_64/extras/cmake-2.8.8-1.el6.rfx.x86_64.html


http://fr2.rpmfind.net//linux/RPM/opensuse/factory/aarch64/aarch64/cmake-3.0.0~rc4-2.1.aarch64.html


2. Bootstrap a tarball such that an end user does not need to have
cmake installed.

What do you mean by 'bootstrapping a tarball' ?

If someone doesn't have cmake installed and downloads a tarball that
was built from a CMake-based project, can they configure/build that
tarball? Or do they have to install cmake first?

___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org

Re: [OMPI users] openmpi configuration error?

[Maxime Boissonneault]

Instead of using the outdated and not maintained Module environment, why 
not use Lmod : https://www.tacc.utexas.edu/tacc-projects/lmod


It is a drop-in replacement for Module environment that supports all of 
their features and much, much more, such as :

- module hierarchies
- module properties and color highlighting (we use it to higlight 
bioinformatic modules or tools for example)
- module caching (very useful for a parallel filesystem with tons of 
modules)
- path priorities (useful to make sure personal modules take precendence 
over system modules)

- export module tree to json

It works like a charm, understand both TCL and Lua modules and is 
actively developped and debugged. There are litteraly new features every 
month or so. If it does not do what you want, odds are that the 
developper will add it shortly (I've had it happen).


Maxime

Le 2014-05-16 17:58, Douglas L Reeder a écrit :

Ben,

You might want to use module (source forge) to manage paths to 
different mpi implementations. It is fairly easy to set up and very 
robust for this type of problem. You would remove contentious 
application paths from you standard PATH and then use module to switch 
them in and out as needed.


Doug Reeder
On May 16, 2014, at 3:39 PM, Ben Lash > wrote:


My cluster has just upgraded to a new version of MPI, and I'm using 
an old one. It seems that I'm having trouble compiling due to the 
compiler wrapper file moving (full error here: 
http://pastebin.com/EmwRvCd9)
"Cannot open configuration file 
/opt/apps/openmpi/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt"


I've found the file on the cluster at 
 /opt/apps/openmpi/retired/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt

How do I tell the old mpi wrapper where this file is?
I've already corrected one link to mpich -> 
/opt/apps/openmpi/retired/1.4.4-intel/, which is in the software I'm 
trying to recompile's lib folder 
(/home/bl10/CMAQv5.0.1/lib/x86_64/ifort). Thanks for any ideas. I 
also tried changing $pkgdatadir based on what I read here:
http://www.open-mpi.org/faq/?category=mpi-apps#default-wrapper-compiler-flags 



Thanks.

--Ben L
___
users mailing list
us...@open-mpi.org 
http://www.open-mpi.org/mailman/listinfo.cgi/users




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



--
-
Maxime Boissonneault
Analyste de calcul - Calcul Québec, Université Laval
Ph. D. en physique

Re: [OMPI users] openmpi configuration error?

[Douglas L Reeder]

Maxime,

I was unaware of Lmod. Thanks for bringing it to my attention.

Doug
On May 16, 2014, at 4:07 PM, Maxime Boissonneault 
 wrote:

> Instead of using the outdated and not maintained Module environment, why not 
> use Lmod : https://www.tacc.utexas.edu/tacc-projects/lmod
> 
> It is a drop-in replacement for Module environment that supports all of their 
> features and much, much more, such as : 
> - module hierarchies
> - module properties and color highlighting (we use it to higlight 
> bioinformatic modules or tools for example)
> - module caching (very useful for a parallel filesystem with tons of modules)
> - path priorities (useful to make sure personal modules take precendence over 
> system modules)
> - export module tree to json
> 
> It works like a charm, understand both TCL and Lua modules and is actively 
> developped and debugged. There are litteraly new features every month or so. 
> If it does not do what you want, odds are that the developper will add it 
> shortly (I've had it happen). 
> 
> Maxime
> 
> Le 2014-05-16 17:58, Douglas L Reeder a écrit :
>> Ben,
>> 
>> You might want to use module (source forge) to manage paths to different mpi 
>> implementations. It is fairly easy to set up and very robust for this type 
>> of problem. You would remove contentious application paths from you standard 
>> PATH and then use module to switch them in and out as needed.
>> 
>> Doug Reeder
>> On May 16, 2014, at 3:39 PM, Ben Lash  wrote:
>> 
>>> My cluster has just upgraded to a new version of MPI, and I'm using an old 
>>> one. It seems that I'm having trouble compiling due to the compiler wrapper 
>>> file moving (full error here: http://pastebin.com/EmwRvCd9)
>>> "Cannot open configuration file 
>>> /opt/apps/openmpi/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt"
>>> 
>>> I've found the file on the cluster at  
>>> /opt/apps/openmpi/retired/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt
>>> How do I tell the old mpi wrapper where this file is?
>>> I've already corrected one link to mpich -> 
>>> /opt/apps/openmpi/retired/1.4.4-intel/, which is in the software I'm trying 
>>> to recompile's lib folder (/home/bl10/CMAQv5.0.1/lib/x86_64/ifort). Thanks 
>>> for any ideas. I also tried changing $pkgdatadir based on what I read here: 
>>> http://www.open-mpi.org/faq/?category=mpi-apps#default-wrapper-compiler-flags
>>> 
>>> Thanks. 
>>> 
>>> --Ben L
>>> ___
>>> users mailing list
>>> us...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>> 
>> 
>> 
>> ___
>> users mailing list
>> us...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
> 
> 
> -- 
> -
> Maxime Boissonneault
> Analyste de calcul - Calcul Québec, Université Laval
> Ph. D. en physique
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

Re: [OMPI users] openmpi configuration error?

[Ben Lash]

I'm not sure I have the ability to implement a different module management
system, I am using a university cluster. We have a module system, and I am
beginning to suspect that maybe it wasn't updated during the upgrade. I have
module list
..other modulesopenmpi/1.4.4
Perhaps this is still trying to go to the old source location? How would I
check? Is there an easy way around it if it is wrong? Thanks again!


On Fri, May 16, 2014 at 5:07 PM, Maxime Boissonneault <
maxime.boissonnea...@calculquebec.ca> wrote:

>  Instead of using the outdated and not maintained Module environment, why
> not use Lmod : https://www.tacc.utexas.edu/tacc-projects/lmod
>
> It is a drop-in replacement for Module environment that supports all of
> their features and much, much more, such as :
> - module hierarchies
> - module properties and color highlighting (we use it to higlight
> bioinformatic modules or tools for example)
> - module caching (very useful for a parallel filesystem with tons of
> modules)
> - path priorities (useful to make sure personal modules take precendence
> over system modules)
> - export module tree to json
>
> It works like a charm, understand both TCL and Lua modules and is actively
> developped and debugged. There are litteraly new features every month or
> so. If it does not do what you want, odds are that the developper will add
> it shortly (I've had it happen).
>
> Maxime
>
> Le 2014-05-16 17:58, Douglas L Reeder a écrit :
>
> Ben,
>
>  You might want to use module (source forge) to manage paths to different
> mpi implementations. It is fairly easy to set up and very robust for this
> type of problem. You would remove contentious application paths from you
> standard PATH and then use module to switch them in and out as needed.
>
>  Doug Reeder
>  On May 16, 2014, at 3:39 PM, Ben Lash  wrote:
>
>  My cluster has just upgraded to a new version of MPI, and I'm using an
> old one. It seems that I'm having trouble compiling due to the compiler
> wrapper file moving (full error here: http://pastebin.com/EmwRvCd9)
> "Cannot open configuration file
> /opt/apps/openmpi/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt"
>
>  I've found the file on the cluster at
>  /opt/apps/openmpi/retired/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt
> How do I tell the old mpi wrapper where this file is?
> I've already corrected one link to mpich -> 
> /opt/apps/openmpi/retired/1.4.4-intel/,
> which is in the software I'm trying to recompile's lib folder
> (/home/bl10/CMAQv5.0.1/lib/x86_64/ifort). Thanks for any ideas. I also
> tried changing $pkgdatadir based on what I read here:
>
> http://www.open-mpi.org/faq/?category=mpi-apps#default-wrapper-compiler-flags
>
>  Thanks.
>
>  --Ben L
>  ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>
>
>
>
> ___
> users mailing 
> listusers@open-mpi.orghttp://www.open-mpi.org/mailman/listinfo.cgi/users
>
>
>
> --
> -
> Maxime Boissonneault
> Analyste de calcul - Calcul Québec, Université Laval
> Ph. D. en physique
>
>
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>



-- 
--Ben L

Re: [OMPI users] openmpi configuration error?

[Gus Correa]

Hi Ben

I guess you are not particularly interested on Modules or LMod either.
You probably don't administer this cluster,
but are just trying to have MPI working, right?


Are you trying to use Open MPI or MPICH?
Your email mentions both.
Let's assume it is Open MPI.

Is recompiling your code with the new version of Open MPI installed
in the cluster an option for you, or not?
If it is, that may be the simplest and best solution.

If the cluster has a system administrator, you may ask him about
the best way to set up your environment variables.

In any case, for your Open MPI to work you need your PATH and 
LD_LIBRARY_PATH to be correctly set.
If the system administator migrated OpenMPI 1.4.4 to a "retired" 
directory, you may need to adjust PATH and LD_LIBRARY_PATH

to point to the "retired" directories (if they are still functional).

echo $PATH
echo $LD_LIBRARY_PATH

may show what you have.

Does the cluster use modules, perhaps?
What do you get from

module list

?

As a workaround you're using bash, you could add these to .bashrc

export PATH=/opt/apps/openmpi/retired/1.4.4-intel/bin:$PATH
export 
LD_LIBRARY_PATH=/opt/apps/openmpi/retired/1.4.4-intel/lib:$LD_LIBRARY_PATH


if csh to .cshrc

setenv PATH /opt/apps/openmpi/retired/1.4.4-intel/bin:$PATH
setenv LD_LIBRARY_PATH 
/opt/apps/openmpi/retired/1.4.4-intel/lib:$LD_LIBRARY_PATH


I hope this helps,
Gus Correa



On 05/16/2014 05:39 PM, Ben Lash wrote:

My cluster has just upgraded to a new version of MPI, and I'm using an
old one. It seems that I'm having trouble compiling due to the compiler
wrapper file moving (full error here: http://pastebin.com/EmwRvCd9)
"Cannot open configuration file
/opt/apps/openmpi/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt"

I've found the file on the cluster at
  /opt/apps/openmpi/retired/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt
How do I tell the old mpi wrapper where this file is?
I've already corrected one link to mpich ->
/opt/apps/openmpi/retired/1.4.4-intel/, which is in the software I'm
trying to recompile's lib folder
(/home/bl10/CMAQv5.0.1/lib/x86_64/ifort). Thanks for any ideas. I also
tried changing $pkgdatadir based on what I read here:
http://www.open-mpi.org/faq/?category=mpi-apps#default-wrapper-compiler-flags

Thanks.

--Ben L


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

Re: [OMPI users] openmpi configuration error?

[Gus Correa]

On 05/16/2014 06:26 PM, Ben Lash wrote:

I'm not sure I have the ability to implement a different module
management system, I am using a university cluster. We have a module
system, and I am beginning to suspect that maybe it wasn't updated
during the upgrade. I have
module list
..other modulesopenmpi/1.4.4
Perhaps this is still trying to go to the old source location? How would
I check? Is there an easy way around it if it is wrong? Thanks again!



Most likely the module openmpi/1.4.4 is out of date.
You can check it with
echo $PATH
If it doesn't point to the "retired" directory, then it is probably out 
of date.


Why don't you try to recompile the code
with the current Open MPI installed in the cluster?

module avail
will show everyting, and you can pick the latest, load it,
and try to recompile the program with that.

Gus Correa



On Fri, May 16, 2014 at 5:07 PM, Maxime Boissonneault
mailto:maxime.boissonnea...@calculquebec.ca>> wrote:

Instead of using the outdated and not maintained Module environment,
why not use Lmod : https://www.tacc.utexas.edu/tacc-projects/lmod

It is a drop-in replacement for Module environment that supports all
of their features and much, much more, such as :
- module hierarchies
- module properties and color highlighting (we use it to higlight
bioinformatic modules or tools for example)
- module caching (very useful for a parallel filesystem with tons of
modules)
- path priorities (useful to make sure personal modules take
precendence over system modules)
- export module tree to json

It works like a charm, understand both TCL and Lua modules and is
actively developped and debugged. There are litteraly new features
every month or so. If it does not do what you want, odds are that
the developper will add it shortly (I've had it happen).

Maxime

Le 2014-05-16 17:58, Douglas L Reeder a écrit :

Ben,

You might want to use module (source forge) to manage paths to
different mpi implementations. It is fairly easy to set up and
very robust for this type of problem. You would remove contentious
application paths from you standard PATH and then use module to
switch them in and out as needed.

Doug Reeder
On May 16, 2014, at 3:39 PM, Ben Lash mailto:b...@rice.edu>> wrote:


My cluster has just upgraded to a new version of MPI, and I'm
using an old one. It seems that I'm having trouble compiling due
to the compiler wrapper file moving (full error here:
http://pastebin.com/EmwRvCd9)
"Cannot open configuration file
/opt/apps/openmpi/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt"

I've found the file on the cluster at
 /opt/apps/openmpi/retired/1.4.4-intel/share/openmpi/mpif90-wrapper-data.txt
How do I tell the old mpi wrapper where this file is?
I've already corrected one link to mpich ->
/opt/apps/openmpi/retired/1.4.4-intel/, which is in the software
I'm trying to recompile's lib folder
(/home/bl10/CMAQv5.0.1/lib/x86_64/ifort). Thanks for any ideas. I
also tried changing $pkgdatadir based on what I read here:

http://www.open-mpi.org/faq/?category=mpi-apps#default-wrapper-compiler-flags


Thanks.

--Ben L
___
users mailing list
us...@open-mpi.org 
http://www.open-mpi.org/mailman/listinfo.cgi/users




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



--
-
Maxime Boissonneault
Analyste de calcul - Calcul Québec, Université Laval
Ph. D. en physique


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




--
--Ben L


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

Re: [OMPI users] openmpi configuration error?

[Ben Lash]

The $PATH and $LD_LIBRARY_PATH seem to be correct, as does module list. I
will try to hear back from our particular cluster people, otherwise I will
try using the latest version. This is old government software, significant
parts are written in fortran77 for example, typically upgrading to a new
version breaks it. It was looking for mpich, hence the link, but a long
time ago I gave it openmpi instead as recommended and that worked, so I
suppose it's less persnickety about the mpi version than some other things.
The most current version installed is openmpi/1.6.5-intel(default). Thanks
again.

[bl10@login2 ~]$ echo $PATH
/home/bl10/rlib/deps/bin:/opt/apps/netcdf/4.1.3/bin:/opt/apps/netcdf/4.1.3/deps/hdf5/1.8.7/bin:/opt/apps/openmpi/retired/1.4.4-intel/bin:/opt/apps/pgi/11.7/linux86-64/11.7/bin:/opt/apps/python3/3.2.1/bin:/opt/apps/intel/2013.1.039/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/ibutils/bin:/opt/apps/moab/current/bin:/projects/dsc1/apps/cmaq/deps/ioapi-kiran/3.1/bin:/home/bl10/bin

[bl10@login2 ~]$ echo $LD_LIBRARY_PATH
/home/bl10/rlib/deps/lib:/projects/dsc1/apps/cmaq/deps/netcdf/4.1.3-intel/lib:/opt/apps/netcdf/4.1.3/lib:/opt/apps/netcdf/4.1.3/deps/hdf5/1.8.7/lib:/opt/apps/netcdf/4.1.3/deps/szip/2.1/lib:/opt/apps/openmpi/retired/1.4.4-intel/lib:/opt/apps/intel/2011.0.013/mkl/lib/intel64:/opt/apps/intel/2013.1.039/mkl/lib/intel64:/opt/apps/intel/2013.1.039/lib/intel64

[bl10@login2 ~]$ module list
Currently Loaded Modulefiles:
  1) intel/2013.1.039  2) python3/3.2.1 3) pgi/11.7
 4) openmpi/1.4.4-intel   5) netcdf/4.1.3
[bl10@login2 ~]$




On Fri, May 16, 2014 at 5:46 PM, Gus Correa  wrote:

> On 05/16/2014 06:26 PM, Ben Lash wrote:
>
>> I'm not sure I have the ability to implement a different module
>> management system, I am using a university cluster. We have a module
>> system, and I am beginning to suspect that maybe it wasn't updated
>> during the upgrade. I have
>> module list
>> ..other modulesopenmpi/1.4.4
>> Perhaps this is still trying to go to the old source location? How would
>> I check? Is there an easy way around it if it is wrong? Thanks again!
>>
>>
> Most likely the module openmpi/1.4.4 is out of date.
> You can check it with
> echo $PATH
> If it doesn't point to the "retired" directory, then it is probably out of
> date.
>
> Why don't you try to recompile the code
> with the current Open MPI installed in the cluster?
>
> module avail
> will show everyting, and you can pick the latest, load it,
> and try to recompile the program with that.
>
> Gus Correa
>
>
>> On Fri, May 16, 2014 at 5:07 PM, Maxime Boissonneault
>> > > wrote:
>>
>> Instead of using the outdated and not maintained Module environment,
>> why not use Lmod : https://www.tacc.utexas.edu/tacc-projects/lmod
>>
>> It is a drop-in replacement for Module environment that supports all
>> of their features and much, much more, such as :
>> - module hierarchies
>> - module properties and color highlighting (we use it to higlight
>> bioinformatic modules or tools for example)
>> - module caching (very useful for a parallel filesystem with tons of
>> modules)
>> - path priorities (useful to make sure personal modules take
>> precendence over system modules)
>> - export module tree to json
>>
>> It works like a charm, understand both TCL and Lua modules and is
>> actively developped and debugged. There are litteraly new features
>> every month or so. If it does not do what you want, odds are that
>> the developper will add it shortly (I've had it happen).
>>
>> Maxime
>>
>> Le 2014-05-16 17:58, Douglas L Reeder a écrit :
>>
>>> Ben,
>>>
>>> You might want to use module (source forge) to manage paths to
>>> different mpi implementations. It is fairly easy to set up and
>>> very robust for this type of problem. You would remove contentious
>>> application paths from you standard PATH and then use module to
>>> switch them in and out as needed.
>>>
>>> Doug Reeder
>>> On May 16, 2014, at 3:39 PM, Ben Lash >> > wrote:
>>>
>>>  My cluster has just upgraded to a new version of MPI, and I'm
 using an old one. It seems that I'm having trouble compiling due
 to the compiler wrapper file moving (full error here:
 http://pastebin.com/EmwRvCd9)
 "Cannot open configuration file
 /opt/apps/openmpi/1.4.4-intel/share/openmpi/mpif90-wrapper-
 data.txt"

 I've found the file on the cluster at
  /opt/apps/openmpi/retired/1.4.4-intel/share/openmpi/mpif90-
 wrapper-data.txt
 How do I tell the old mpi wrapper where this file is?
 I've already corrected one link to mpich ->
 /opt/apps/openmpi/retired/1.4.4-intel/, which is in the software
 I'm trying to recompile's lib folder
 (/home/bl10/CMAQv5.0.1/lib/x86_64/ifort). Than

Re: [OMPI users] openmpi configuration error?

[Gus Correa]

On 05/16/2014 07:09 PM, Ben Lash wrote:

The $PATH and $LD_LIBRARY_PATH seem to be correct, as does module list.
I will try to hear back from our particular cluster people, otherwise I
will try using the latest version. This is old government software,
significant parts are written in fortran77 for example, typically
upgrading to a new version breaks it. It was looking for mpich, hence
the link, but a long time ago I gave it openmpi instead as recommended
and that worked, so I suppose it's less persnickety about the mpi
version than some other things. The most current version installed
is openmpi/1.6.5-intel(default). Thanks again.



We have code here that has been recompiled (some with modifications, 
some not) with OpenMPI since 1.2.8 with no problems.
MPI is a standard, both OpenMPI and MPICH follow the standard (except 
perhaps for very dusty corners or latest greatest MPI 3 features).

If your code compiled with 1.4.4, it should (better) do with 1.6.5.
Fortran77 shouldn't be an issue.

I agree, the PATH and LD_LIBRARY_PATH point to the "retired" directory.
Many things may have happened, though, say, the "retired" directory may 
not be complete, or may not have been installed on all cluster nodes,
or (if not really re-installed) probably points to the original 
(pre-retirement) directories that no longer exist.

Rather than sorting this out, I think you have a better shot using
Open MPI 1.6.5.
Just load the module and try to recompile the code.
(Probably just
module swap openmpi/1.4.4-intel openmpi/1.6.5-intel)

You may need to tweak with the Makefile, if it hardwires
the MPI wrappers/binary location, or the library and include paths.
Some do, some don't.

Gus Correa



[bl10@login2 ~]$ echo $PATH
/home/bl10/rlib/deps/bin:/opt/apps/netcdf/4.1.3/bin:/opt/apps/netcdf/4.1.3/deps/hdf5/1.8.7/bin:/opt/apps/openmpi/retired/1.4.4-intel/bin:/opt/apps/pgi/11.7/linux86-64/11.7/bin:/opt/apps/python3/3.2.1/bin:/opt/apps/intel/2013.1.039/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/ibutils/bin:/opt/apps/moab/current/bin:/projects/dsc1/apps/cmaq/deps/ioapi-kiran/3.1/bin:/home/bl10/bin

[bl10@login2 ~]$ echo $LD_LIBRARY_PATH
/home/bl10/rlib/deps/lib:/projects/dsc1/apps/cmaq/deps/netcdf/4.1.3-intel/lib:/opt/apps/netcdf/4.1.3/lib:/opt/apps/netcdf/4.1.3/deps/hdf5/1.8.7/lib:/opt/apps/netcdf/4.1.3/deps/szip/2.1/lib:/opt/apps/openmpi/retired/1.4.4-intel/lib:/opt/apps/intel/2011.0.013/mkl/lib/intel64:/opt/apps/intel/2013.1.039/mkl/lib/intel64:/opt/apps/intel/2013.1.039/lib/intel64

[bl10@login2 ~]$ module list
Currently Loaded Modulefiles:
   1) intel/2013.1.039  2) python3/3.2.1 3) pgi/11.7
  4) openmpi/1.4.4-intel   5) netcdf/4.1.3
[bl10@login2 ~]$




On Fri, May 16, 2014 at 5:46 PM, Gus Correa mailto:g...@ldeo.columbia.edu>> wrote:

On 05/16/2014 06:26 PM, Ben Lash wrote:

I'm not sure I have the ability to implement a different module
management system, I am using a university cluster. We have a module
system, and I am beginning to suspect that maybe it wasn't updated
during the upgrade. I have
module list
..other modulesopenmpi/1.4.4
Perhaps this is still trying to go to the old source location?
How would
I check? Is there an easy way around it if it is wrong? Thanks
again!


Most likely the module openmpi/1.4.4 is out of date.
You can check it with
echo $PATH
If it doesn't point to the "retired" directory, then it is probably
out of date.

Why don't you try to recompile the code
with the current Open MPI installed in the cluster?

module avail
will show everyting, and you can pick the latest, load it,
and try to recompile the program with that.

Gus Correa


On Fri, May 16, 2014 at 5:07 PM, Maxime Boissonneault
mailto:maxime.boissonnea...@calculquebec.ca>
>> wrote:

 Instead of using the outdated and not maintained Module
environment,
 why not use Lmod :
https://www.tacc.utexas.edu/__tacc-projects/lmod


 It is a drop-in replacement for Module environment that
supports all
 of their features and much, much more, such as :
 - module hierarchies
 - module properties and color highlighting (we use it to
higlight
 bioinformatic modules or tools for example)
 - module caching (very useful for a parallel filesystem
with tons of
 modules)
 - path priorities (useful to make sure personal modules take
 precendence over system modules)
 - export module tree to json

 It works like a charm, understand both TCL and Lua modules
and is
 actively developped and debugged. T