Re: [OMPI users] MPI::Request::Test not working
It looks like you are using C++ improperly. I would suggest something like
this (typed in email; not verified with a compiler):
MPI::Request Isend_request;
Isend_request = MPI::COMM_WORLD.Isend(...);
MPI::Status status;
if (Isend_request.Test(status)) {
// ...
}
On Dec 30, 2011, at 10:21 PM, devendra rai wrote:
> Hello Everyone,
>
> I wrote a small C++ MPI program to do an ISend:
>
> /*some declarations here */
> MPI::Request Isend_request_status;
> ...
> ...
>
> /* do the transmission */
> Isend_request_status = MPI::COMM_WORLD.Isend(this->transmitbuffer,
> this->transmissionsize, MPI_BYTE, (this->dbIterator)->first,
> std::get<0>(this->TransmissionDetails));
>
> /* Check if the transmit was successful */
> if (MPI::Request::Test(Isend_request_status))
> {
> /* done :) */
> }
>
> However, building it gives the error:
>
> no matching function for call to ‘MPI::Request::Test(MPI::Request&)’
>
> I am using gcc-4.6 on Linux, with OpenMPI- 1.4.3.
>
> I looked up the headers for the calls:
>
> inline MPI::Request
> MPI::Comm::Isend(const void *buf, int count,
> const MPI::Datatype & datatype, int dest, int tag) const
>
> So, the MPI::COMM_WORLD::ISend(...) should return me variable of type
> MPI::Request.
>
> And,
>
> inline bool
> MPI::Request::Test(MPI::Status &status)
>
> This takes in the variable of type MPI::Status.
>
>
> So, two questions:
>
> (1). Is there a problem due to incompatible types? If so, how do I fix it?
> (2). Why would the MPI::Request::Test take in a different type than what is
> returned by MPI::COMM_WORLD::ISend(...)?
>
> It would really help if you could help me fix the example that I have shown.
>
> I understand it would be easier to do this in C, but there are project
> requirements that led me to C++.
>
> Can someone please help?
>
> Thanks a lot.
>
>
> Devendra
> sd
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI users] possibly undefined macro: AC_PROG_LIBTOOL
I don't know if I've tried explicitly with 2.67, but I'd be surprised if it doesn't recognize AC_PROG_LIBTOOL. Also note that AC_PROG_LIBTOOL comes from Libtool, not Autoconf. FWIW, I've seen this kind of error when AC/AM/LT are not installed to the same tree. If they're installed to different trees (i.e., with a different --prefix value when you run configure to install them), you'll almost certainly run into this kind of problem. I'm not sure how Debian Squeeze installs the autotools packages, but if it supports multiple backports of those same packages simultaneously, they could well be installed to different directories, and therefore there might be some restrictions on installing / using them correctly. FWIW, I just FTP those 4 packages separately from my OS (AC, AM, LT, M4) and configure/make install them myself to a separate side directory (e.g., $HOME/autotools). That prevents all these kind of OS packaging issues. On Dec 29, 2011, at 7:24 PM, Ralph Castain wrote: > I use 2.68 and 2.65 and have no problems. Could be that 2.67 has a problem - > perhaps try with one of the other levels? > > > On Dec 29, 2011, at 5:14 PM, Dmitry N. Mikushin wrote: > >> OK, apparently that were various backports. And now I have only one >> autoconf installed, and it is: >> >> marcusmae@teslatron:~/Programming/openmpi-r24785$ autoconf --version >> autoconf (GNU Autoconf) 2.67 >> >> marcusmae@teslatron:~/Programming/openmpi-r24785$ autoreconf --version >> autoreconf (GNU Autoconf) 2.67 >> >> However: >> >> 6. Processing autogen.subdirs directories >> >> === Processing subdir: >> /home/marcusmae/Programming/openmpi-r24785/opal/mca/event/libevent207/libevent >> --- Found autogen.sh; running... >> autoreconf: Entering directory `.' >> autoreconf: configure.in: not using Gettext >> autoreconf: running: aclocal --force -I m4 >> autoreconf: configure.in: tracing >> autoreconf: configure.in: not using Libtool >> autoreconf: running: /usr/bin/autoconf --force >> configure.in:113: error: possibly undefined macro: AC_PROG_LIBTOOL >> If this token and others are legitimate, please use m4_pattern_allow. >> See the Autoconf documentation. >> autoreconf: /usr/bin/autoconf failed with exit status: 1 >> Command failed: ./autogen.sh >> >> Does it work for you with 2.67? >> >> Thanks, >> - D. >> >> 2011/12/30 Ralph Castain : >>> >>> On Dec 29, 2011, at 3:39 PM, Dmitry N. Mikushin wrote: >>> No, that was autoREconf, and all they are below 2.65: marcusmae@teslatron:~/Programming/openmpi-r24785$ ls /usr/bin/autoreconf autoreconf autoreconf2.13 autoreconf2.50 autoreconf2.59 autoreconf2.64 And default one points to 2.50: marcusmae@teslatron:~/Programming/openmpi-r24785$ autoreconf -help Usage: /usr/bin/autoreconf2.50 [OPTION]... [DIRECTORY]... I don't know why, probably that's the default Debian Squeeze setup? >>> >>> Probably - but that's no good. It should be the same level as autoconf as >>> the two are packaged together to avoid incompatibilities like you are >>> hitting here. Did you install autoconf yourself? If so, can you point >>> autoreconf to the corresponding binary? >>> - D. 2011/12/30 Ralph Castain : > Strange - if you look at your original output, autoconf is identified as > 2.50 - a version that is way too old for us. However, what you just sent > now shows 2.67, which would be fine. > > Why the difference? > > > On Dec 29, 2011, at 3:27 PM, Dmitry N. Mikushin wrote: > >> Hi Ralph, >> >> URL: http://svn.open-mpi.org/svn/ompi/trunk >> Repository Root: http://svn.open-mpi.org/svn/ompi >> Repository UUID: 63e3feb5-37d5-0310-a306-e8a459e722fe >> Revision: 24785 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: rhc >> Last Changed Rev: 24785 >> Last Changed Date: 2011-06-17 22:01:23 +0400 (Fri, 17 Jun 2011) >> >> 1. Checking tool versions >> >> Searching for autoconf >>Found autoconf version 2.67; checking version... >> Found version component 2 -- need 2 >> Found version component 67 -- need 65 >>==> ACCEPTED >> Searching for libtoolize >>Found libtoolize version 2.2.6b; checking version... >> Found version component 2 -- need 2 >> Found version component 2 -- need 2 >> Found version component 6b -- need 6b >>==> ACCEPTED >> Searching for automake >>Found automake version 1.11.1; checking version... >> Found version component 1 -- need 1 >> Found version component 11 -- need 11 >> Found version component 1 -- need 1 >>==> ACCEPTED >> >> 2011/12/30 Ralph Castain : >>> Are you doing this on a subversion checkout? Of which branch? >>> >>> Did you check your autotoll versions to ensure you meet the minimum >>> required le
[OMPI users] MPI-2 in MX (was: MPI 2 support in sm btl)
I'm afraid I don't know offhand -- but I do have a dim recollection that MX requires all processes to be available at INIT time (i.e., processes that join later, e.g., via MPI-2 dynamics, will not communicate via MX). That may or may not be true -- don't hold me to that. Can someone who knows MX better than me comment about this? On Dec 28, 2011, at 8:58 AM, Sabela Ramos Garea wrote: > Thanks for your answers. > Is there a similar issue with mx BTL? I mean, using the mx BTL, is it > possible to reach a parent job from a spawned process? > > Thanks again! :-) > > El 16 de diciembre de 2011 15:08, Jeff Squyres escribió: > On Dec 14, 2011, at 4:01 PM, Ralph Castain wrote: > > >> As far as I know, there is no support for some MPI-2 features in the > >> shared memory BTL as dynamic process creation or port connection. Are you > >> planning to include this support? > > > > It depends on what exactly you mean. Dynamically spawned processes do use > > the shared memory BTL between themselves, but not with the processes in > > their parent job. We plan to support that as well at some future time. > > ...when enough people ask for it. :-) > > We've talked about supporting this for a long time, but to be blunt, there > hasn't been enough demand for it to justify spending the time to figure out > all the issues and implement it properly. :-( > > Patches would be welcome, though! :-) > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > ___ > 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 -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI users] Latest Intel Compilers (ICS, version 12.1.0.233 Build 20110811) issues ...
Tim/All,
Thanks ... !! ... your response is on target, version 12.1.0.233 of the Intel
compiler has a vectorization bug.
Moreover, this problem has been addressed with the following go-around
in the 1.5.5 OpenMPI release with the following fix in
opal/mca/memory/linux/malloc.c:
/* With Intel Composer XE V12.1.0, release 2011.6.233, any launch */
/* fails, even before main(), due to a bug in the vectorizer (see */
/* https://svn.open-mpi.org/trac/ompi/changeset/25290). The fix is */
/* to disable vectorization by reducing the optimization level to */
/* -O1 for _int_malloc(). The only reliable method to identify */
/* release 2011.6.233 is the predefined __INTEL_COMPILER_BUILD_DATE */
/* macro, which will have the value 20110811 (Linux, Windows, and */
/* Mac OS X). (The predefined __INTEL_COMPILER macro is nonsense, */
/* , and both the 2011.6.233 and 2011.7.256 releases identify */
/* themselves as V12.1.0 from the -v command line option.) */
#ifdef __INTEL_COMPILER_BUILD_DATE
# if __INTEL_COMPILER_BUILD_DATE == 20110811
#pragma GCC optimization_level 1
# endif
#endif
So, anyone with the NEWEST Intel compiler should either use the 1.5.5
release or add the above section to the malloc.c code. Note earlier releases
have a slightly different directory location for the 'memory.c' code, but it
is easy to find.
Thanks Tim ... !!
Sincerely,
rbw
Richard Walsh
Parallel Applications and Systems Manager
CUNY HPC Center, Staten Island, NY
W: 718-982-3319
M: 612-382-4620
Right, as the world goes, is only in question between equals in power, while
the strong do what they can and the weak suffer what they must. -- Thucydides,
400 BC
From: users-boun...@open-mpi.org [users-boun...@open-mpi.org] on behalf of Tim
Carlson [tim.carl...@pnl.gov]
Sent: Tuesday, January 03, 2012 4:52 PM
To: Open MPI Users
Subject: Re: [OMPI users] Latest Intel Compilers (ICS, version 12.1.0.233 Build
20110811) issues ...
On Tue, 3 Jan 2012, Richard Walsh wrote:
OPAL has problems with the default optimization. See this thread on one of
the Intel lists.
vi opal/mca/memory/linux/malloc.c
add #pragma optimize("", off)
http://software.intel.com/en-us/forums/showthread.php?t=87132
>
> Gus/All,
>
> Perhaps there is some confusion as to which 'new' Intel compiler
> release/version I
> am using. I am not using '12.0' ... I am using '12.1' ...
>
> OLD one that builds a working opal_wrapper:
>
> [richard.walsh@athena ~]$ icc -V
> Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64,
> Version 12.0.0.084 Build 20101006
> Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
>^
>
> NEW one that FAILS to build a working opal_wrapper:
>
> [root@zeus .libs]# icc -V
> Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64,
> Version 12.1.0.233 Build 20110811
> Copyright (C) 1985-2011 Intel Corporation. All rights reserved.
>^
>
> This was in my original email. NOTE: that the non-working version is 12.1
> >>NOT<< 12.0 This '12.1'
> version was released by Intel JUST BEFORE SC11 in October of 2011.
>
> Thanks,
>
> rbw
>
>
> Richard Walsh
> Parallel Applications and Systems Manager
> CUNY HPC Center, Staten Island, NY
> W: 718-982-3319
> M: 612-382-4620
>
> Right, as the world goes, is only in question between equals in power, while
> the strong do what they can and the weak suffer what they must. --
> Thucydides, 400 BC
>
>
> From: users-boun...@open-mpi.org [users-boun...@open-mpi.org] on behalf of
> Gustavo Correa [g...@ldeo.columbia.edu]
> Sent: Tuesday, January 03, 2012 4:28 PM
> To: Open MPI Users
> Subject: Re: [OMPI users] Latest Intel Compilers (ICS, version 12.1.0.233
> Build 20110811) issues ...
>
> Hi Richard
>
> I have 1.4.4 built with Intel 12.0. It works.
>
> Any chance that your Intel-based OpenMPI was built from a source
> directory that had been previously used to build the PGI-based OpenMPI,
> and no 'make distclean' was issued in between the two builds,
> nor a fresh build done from a brand new tarball?
> Just a wild guess.
>
> I hope it helps,
> Gus Correa
>
> On Jan 3, 2012, at 11:23 AM, Richard Walsh wrote:
>
>>
>> Jonathan/All,
>>
>> Thanks for the information, but I continue to have problems. I dropped the
>> 'openib' option to simplify things and focused my attention only on OpenMPI
>> version 1.4.4 because you suggested it works.
>>
>> On the strength of the fact that the PGI 11.10 compiler works fine (all
>> systems
>> and all versions of OpenMPI), I ran a PGI build of 1.4.4 with the '-showme'
>> option (Intel fails immediately, even with '-showme' ... ). I then
>> substituted all
>> the PGI-related strings with Intel-related strings to compile directly and
>> explicitly
>> outside the 'opal' wrapper using code and libraries in the Intel build tree
Re: [OMPI users] MPI::Request::Test not working
Hi Jeff
Thanks a lot. Yeah, I figured that out. Anyway, even in C++ program, I am using
C interfaces for the MPI bit. For me, its lot easier to understand the
documentation and help this way.
Thanks a lot once again.
Best,
Devendra
From: Jeff Squyres
To: devendra rai ; Open MPI Users
Sent: Wednesday, 4 January 2012, 13:21
Subject: Re: [OMPI users] MPI::Request::Test not working
It looks like you are using C++ improperly. I would suggest something like
this (typed in email; not verified with a compiler):
MPI::Request Isend_request;
Isend_request = MPI::COMM_WORLD.Isend(...);
MPI::Status status;
if (Isend_request.Test(status)) {
// ...
}
On Dec 30, 2011, at 10:21 PM, devendra rai wrote:
> Hello Everyone,
>
> I wrote a small C++ MPI program to do an ISend:
>
> /*some declarations here */
> MPI::Request Isend_request_status;
> ...
> ...
>
> /* do the transmission */
> Isend_request_status = MPI::COMM_WORLD.Isend(this->transmitbuffer,
> this->transmissionsize, MPI_BYTE, (this->dbIterator)->first,
> std::get<0>(this->TransmissionDetails));
>
> /* Check if the transmit was successful */
> if (MPI::Request::Test(Isend_request_status))
> {
> /* done :) */
> }
>
> However, building it gives the error:
>
> no matching function for call to ‘MPI::Request::Test(MPI::Request&)’
>
> I am using gcc-4.6 on Linux, with OpenMPI- 1.4.3.
>
> I looked up the headers for the calls:
>
> inline MPI::Request
> MPI::Comm::Isend(const void *buf, int count,
> const MPI::Datatype & datatype, int dest, int tag) const
>
> So, the MPI::COMM_WORLD::ISend(...) should return me variable of type
> MPI::Request.
>
> And,
>
> inline bool
> MPI::Request::Test(MPI::Status &status)
>
> This takes in the variable of type MPI::Status.
>
>
> So, two questions:
>
> (1). Is there a problem due to incompatible types? If so, how do I fix it?
> (2). Why would the MPI::Request::Test take in a different type than what is
> returned by MPI::COMM_WORLD::ISend(...)?
>
> It would really help if you could help me fix the example that I have shown.
>
> I understand it would be easier to do this in C, but there are project
> requirements that led me to C++.
>
> Can someone please help?
>
> Thanks a lot.
>
>
> Devendra
> sd
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
[OMPI users] Can we avoid derived datatypes?
Hello All, I need to send a struct- datatype over MPI. Currently, I send the strcture as a series of MPI_BYTEs and on the other end, I dereference it as though it were a struct- type. Something like this: MPI_Ssend((void*)&MasterSlavePayload, sizeof(MasterSlavePayload), MPI_BYTE, destNode,MASTERSLAVECONTROLMESSAGE,MPI_COMM_WORLD); where MasterSlavePayload is a structure variable. This currently seems to work, where we have a homogenous environment: same hardware configuration, and same operating system. The question is: Is this approach portable? Safe? And whether this will work on a system of nodes with mixed processor types? I read from MPI tutorials "...Primitive data types are contiguous. Derived data types allow you to specify non-contiguous data in a convenient manner and to treat it as though it was contiguous. " So, since I am using a primitive data type, does it mean that the packing of elements is maintained across the MPI_Send/MPI_Recv process? If so, it would mean that the approach that I use should work. Any ideas? Thanks a lot, best Devendra
Re: [OMPI users] Error launching w/ 1.5.3 on IB mthca nodes
Hello. Sorry for the delay in confirming the minimum load that would trigger the RnR error; the holidays here were a significant interruption. On Mon, Dec 19, 2011, at 03:30 PM, Yevgeny Kliteynik wrote: > What's the smallest number of nodes that are needed to reproduce this > problem? Does it happen with just two HCAs, one process per node? Our nodes with these HCAs are dual-socket, 4 Intel cores/socket. Working with the users, it turns out we were unable to reproduce the issue with anything less than 3 nodes and 17 processes total, with no nodes oversubscribed. So two nodes were running with 8 processes each and the third with 1 process. It could be some sort of race condition or timing issue that could theoretically be triggered for less than this, but we weren't able to provoke it. > Let's get you to the latest firmware GA of this card. Just as a reminder, I responded to the firmware part of this earlier: http://www.open-mpi.org/community/lists/users/2011/12/18014.php Thank you, V. Ram -- http://www.fastmail.fm - Access your email from home and the web
