[OMPI users] Can I run MPI and non MPI programs together
I have openmpi installed and running, but have a need to run non mpi
programs (3rd party software for which I don't have the source) together
with mpi programs.
Have managed to simplify the problem down to the following
JobA
int main(.)
{
printf("Starting JobA\n");
MPI::Init();
printf("JobA Init done\n");
}
JobB
Int main(.)
{
printf("Starting JobB\n");
}
And running with
mpirun -mca btl tcp,self,sm -np 1 -host lyre JobA : -np 1 -host lyre JobB
The output is the two messages "Starting ." message and then hangs.
It would appear that the MPI::Init() is waiting for all Ranks to call
MPI::Init() before continuing.
Please note the above works as expected if we run either two JobAs or two
JobBs. Only have a problem if there is a mixture of JobAs and JobBs.
Is there a way around this problem?
Thanks in advance Neville
Re: [OMPI users] Can I run MPI and non MPI programs together
Hi Tim,
dah, why did I not think of that? So simple.
Thanks again.
> -Original Message-
> From: users-boun...@open-mpi.org [mailto:users-boun...@open-mpi.org] On
> Behalf Of Tim Prins
> Sent: Monday, 9 July 2007 10:41 AM
> To: n...@nevclark.com; Open MPI Users
> Subject: Re: [OMPI users] Can I run MPI and non MPI programs together
>
> On Sunday 08 July 2007 08:22:04 pm Neville Clark wrote:
> > I have openmpi installed and running, but have a need to run non mpi
> > programs (3rd party software for which I don't have the source) together
> > with mpi programs.
> >
> > Have managed to simplify the problem down to the following
> >
> > JobA
> > int main(.)
> > {
> > printf("Starting JobA\n");
> > MPI::Init();
> > printf("JobA Init done\n");
> > }
> >
> > JobB
> > Int main(.)
> > {
> > printf("Starting JobB\n");
> > }
> >
> > And running with
> > mpirun -mca btl tcp,self,sm -np 1 -host lyre JobA : -np 1 -host lyre
> JobB
> >
> > The output is the two messages "Starting ." message and then hangs.
> >
> > It would appear that the MPI::Init() is waiting for all Ranks to call
> > MPI::Init() before continuing.
> This is correct. You cannot run both mpi and non-mpi processes like this
> together. The best you can do is run mpirun twice.
>
> Hope this helps,
>
> Tim
>
> >
> > Please note the above works as expected if we run either two JobAs or
> two
> > JobBs. Only have a problem if there is a mixture of JobAs and JobBs.
> >
> > Is there a way around this problem?
> >
> > Thanks in advance Neville
>
>
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
Re: [OMPI users] Fwd: Problems installing in Cygwin
George (or anyone else that can help), I have been trying to build OpenMPI for windows (XP). But so far have not been successful. I am trying to build version 1.3b2, because of these emails, I have setup two virtual machine to do the windows builds, one with cygwin installed and one with Microsoft Visual Studio 9.0 (express) installed. Using slightly modified command that Gustavo used ./configure --prefix=/home/seabra/local/openmpi-1.3b1 \ --with-mpi-param_check=always --with-threads=posix \ --enable-mpi-threads --disable-io-romio \ --enable-mca-no-build=memory_mallopt,maffinity,paffinity \ --enable-contrib-no-build=vt \ CXX=g++ I was able to get configure to run, but the 'make all' failed. Before trying to debug the Cygwin build (which is very slow), I want to try the native windows build, but dont know how to proceed. Is there a MSVC project file? Or should I use Cygwin to run configure, but use the microsoft compiler and linker? I have not yet looked into using SFU. Thank you in advance Nev -Original Message- From: George Bosilca Reply-To: Open MPI Users To: Open MPI Users Subject: Re: [OMPI users] Fwd: Problems installing in Cygwin List-Post: users@lists.open-mpi.org Date: Thu, 30 Oct 2008 09:04:48 -0400 Gustavo, As Jeff mentioned this component is not required on Windows. You can disable it completely in Open MPI and everything will continue to work correctly. Please add --enable-mca-no-build=memory_mallopt o maybe the more generic (as there is no need for any memory manager on Windows -- enable-mca-no-build=memory. Just a word about performance. I think you already noticed how long the configure step is, and believe it is fast compared with building the whole Open MPI. However, once built, Open MPI (and most of Cygwin applications) only see their performance slightly affected by the fact they run on Cygwin. Even the network performances are correct. It is possible to have a native version of Open MPI on Windows. There are two ways to achieve this. First, install SFU, and compile there. It worked last time I checked, but it's not the solution I prefer. Second, you can install the express version of the Microsoft Visual Studio (which is free), and set your PATH, LIB and INCLUDE correctly to point to the installation, and then you can use the cl compiler to build Open MPI even on Windows. george. On Oct 30, 2008, at 8:40 AM, Jeff Squyres wrote: > On Oct 29, 2008, at 4:31 PM, Gustavo Seabra wrote: > >>> Ugh. IMHO, Cygwin != POSIX. >>> >>> The problem is that we're making the assumption that if dlsym() is >>> present, >>> RTLD_NEXT is defined. I guess that's not true for cygwin (lame). >>> I suppose >>> that we could also check for RTLD_NEXT...? Is there any other OS >>> where >>> dlsym() is present by RTLD_NEXT is not? >>> >>> Would it be easier to run Linux in a virtual machine on your >>> windows host? >>> You'll probably get a lot better performance...? >> >> Hi Jeff, >> >> Are you sure RTLD_NEXT is part of the POSIX standard? I may be >> looking >> in the wrong place, but apparently it is *not* part of the standard, >> at least as defined here: >> >> http://www.opengroup.org/onlinepubs/95399/basedefs/dlfcn.h.html > > Fair enough -- my words were ambiguous, and probably overly broad. > I was trying to convey that my prior experience with Cygwin has > biased me to believe that Cygwin tends to be "different" than other > POSIX-like OSs, such as Linux, Solaris, and OS X. > >> It would seem that this is a GNU extension, so it becomes available >> when __USE_GNU is defined. Now, looking at the cygwin version of >> dlfcn.h, I see that RTDL_NEXT is *not* defined, but RTDL_LAZY, >> RTLD_NOW, RTLD_LOCAL and RTLD_GLOBAL, which makes it compliant with >> POSIX, but not GNU. >> >> The 'memory_mallopt_component.c' only checks if 'HAVE_DLSYM' is >> defined. If so, it defines __USE_GNU then includes dlfcn.h. This is >> ok, assuming you have a GNU version of dlfcn.h, but apparently this >> is >> not present in Cygwin... > > Understood; this was a more complete/precise meaning for my question > "Is there any other OS where > dlsym() is present by RTLD_NEXT is not?" I suppose we can extend > the configure test to check for RTLD_NEXT as well. In this way, > that component won't even decide to build itself. You won't need > this component, because it's only really useful for the OpenFabrics > and [ancient] Myricom GM drivers in Open MPI, neither of which are > likely to be supported in Cygwin. > > Also FWIW, my understanding is that running another OS in a VM (such > as Linux or your favorite BSD) will run *much* faster than Cygwin. > I have dim recollections of LAM's and OMPI's "configure" script > taking loong periods of time (I no longer have easy access to a > Windows machine to do such testing). Those with more Windows > experience than me attributed it to Wi
Re: [OMPI users] Fwd: Problems installing in Cygwin
Hi all, Update to build attempt. I have a successful build using Cygwin with the following command $ ./configure --prefix=/opt/openmpi-1.3b2 \ --enable-mca-no-build=memory_mallopt,paffinity But I also had problem with "max" being defined somewhere. I was able to locate it to the following line #include MCA_timer_IMPLEMENTATION_HEADER in "ompi/tools/ompi_info/param.cc" adding #define NOMINMAX before the include and #undef NOMINMAX after line fixed the problem. I have not yet found the file included by above line, but it most likely includes windows.h which will define min and max. Hopefully this is helpful. BUT I would still like help on how to build in native windows. Thanks Nev -Original Message- From: Neville Clark Reply-To: Open MPI Users To: Open MPI Users Subject: Re: [OMPI users] Fwd: Problems installing in Cygwin List-Post: users@lists.open-mpi.org Date: Wed, 12 Nov 2008 20:13:53 +1100 George (or anyone else that can help), I have been trying to build OpenMPI for windows (XP). But so far have not been successful. I am trying to build version 1.3b2, because of these emails, I have setup two virtual machine to do the windows builds, one with cygwin installed and one with Microsoft Visual Studio 9.0 (express) installed. Using slightly modified command that Gustavo used ./configure --prefix=/home/seabra/local/openmpi-1.3b1 \ --with-mpi-param_check=always --with-threads=posix \ --enable-mpi-threads --disable-io-romio \ --enable-mca-no-build=memory_mallopt,maffinity,paffinity \ --enable-contrib-no-build=vt \ CXX=g++ I was able to get configure to run, but the 'make all' failed. Before trying to debug the Cygwin build (which is very slow), I want to try the native windows build, but dont know how to proceed. Is there a MSVC project file? Or should I use Cygwin to run configure, but use the microsoft compiler and linker? I have not yet looked into using SFU. Thank you in advance Nev -Original Message- From: George Bosilca Reply-To: Open MPI Users To: Open MPI Users Subject: Re: [OMPI users] Fwd: Problems installing in Cygwin List-Post: users@lists.open-mpi.org Date: Thu, 30 Oct 2008 09:04:48 -0400 Gustavo, As Jeff mentioned this component is not required on Windows. You can disable it completely in Open MPI and everything will continue to work correctly. Please add --enable-mca-no-build=memory_mallopt o maybe the more generic (as there is no need for any memory manager on Windows -- enable-mca-no-build=memory. Just a word about performance. I think you already noticed how long the configure step is, and believe it is fast compared with building the whole Open MPI. However, once built, Open MPI (and most of Cygwin applications) only see their performance slightly affected by the fact they run on Cygwin. Even the network performances are correct. It is possible to have a native version of Open MPI on Windows. There are two ways to achieve this. First, install SFU, and compile there. It worked last time I checked, but it's not the solution I prefer. Second, you can install the express version of the Microsoft Visual Studio (which is free), and set your PATH, LIB and INCLUDE correctly to point to the installation, and then you can use the cl compiler to build Open MPI even on Windows. george. On Oct 30, 2008, at 8:40 AM, Jeff Squyres wrote: > On Oct 29, 2008, at 4:31 PM, Gustavo Seabra wrote: > >>> Ugh. IMHO, Cygwin != POSIX. >>> >>> The problem is that we're making the assumption that if dlsym() is >>> present, >>> RTLD_NEXT is defined. I guess that's not true for cygwin (lame). >>> I suppose >>> that we could also check for RTLD_NEXT...? Is there any other OS >>> where >>> dlsym() is present by RTLD_NEXT is not? >>> >>> Would it be easier to run Linux in a virtual machine on your >>> windows host? >>> You'll probably get a lot better performance...? >> >> Hi Jeff, >> >> Are you sure RTLD_NEXT is part of the POSIX standard? I may be >> looking >> in the wrong place, but apparently it is *not* part of the standard, >> at least as defined here: >> >> http://www.opengroup.org/onlinepubs/95399/basedefs/dlfcn.h.html > > Fair enough -- my words were ambiguous, and probably overly broad. > I was trying to convey that my prior experience with Cygwin has > biased me to believe that Cygwin tends to be "different" than other > POSIX-like OSs, such as Linux, Solaris, and OS X. > >> It would seem that this is a GNU extension, so it becomes available >> when __USE_GNU is defined. Now, looking at the cygwin version of >> dlfcn.h, I see that RTDL_NEXT is *not* defined, but RTDL_LAZY, >> RTLD_NO
