Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] users Digest, Vol 1055, Issue 2
From: Rima Chaudhuri (rima.chaudhuri_at_[hidden])
Date: 2008-11-03 15:39:44


Thanks a lot Ralph!
I corrected the no_local to nolocal and now when I try to execute the
script step1 (pls find it attached)
[rchaud_at_helios amber10]$ ./step1
[helios.structure.uic.edu:16335] [0,0,0] ORTE_ERROR_LOG: Not available
in file ras_bjs.c at line 247
--------------------------------------------------------------------------
There are no available nodes allocated to this job. This could be because
no nodes were found or all the available nodes were already used.

Note that since the -nolocal option was given no processes can be
launched on the local node.
--------------------------------------------------------------------------
[helios.structure.uic.edu:16335] [0,0,0] ORTE_ERROR_LOG: Temporarily
out of resource in file base/rmaps_base_support_fns.c at line 168
[helios.structure.uic.edu:16335] [0,0,0] ORTE_ERROR_LOG: Temporarily
out of resource in file rmaps_rr.c at line 402
[helios.structure.uic.edu:16335] [0,0,0] ORTE_ERROR_LOG: Temporarily
out of resource in file base/rmaps_base_map_job.c at line 210
[helios.structure.uic.edu:16335] [0,0,0] ORTE_ERROR_LOG: Temporarily
out of resource in file rmgr_urm.c at line 372
[helios.structure.uic.edu:16335] mpirun: spawn failed with errno=-3

If I use the script without the --nolocal option, I get the following error:
[helios.structure.uic.edu:20708] [0,0,0] ORTE_ERROR_LOG: Not available
in file ras_bjs.c at line 247

thanks,

On Mon, Nov 3, 2008 at 2:04 PM, <users-request_at_[hidden]> wrote:
> Send users mailing list submissions to
> users_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.open-mpi.org/mailman/listinfo.cgi/users
> or, via email, send a message with subject or body 'help' to
> users-request_at_[hidden]
>
> You can reach the person managing the list at
> users-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
> 1. Scyld Beowulf and openmpi (Rima Chaudhuri)
> 2. Re: Scyld Beowulf and openmpi (Ralph Castain)
> 3. Problems installing in Cygwin - Problem with GCC 3.4.4
> (Gustavo Seabra)
> 4. Re: MPI + Mixed language coding(Fortran90 + C++) (Jeff Squyres)
> 5. Re: Problems installing in Cygwin - Problem with GCC 3.4.4
> (Jeff Squyres)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 3 Nov 2008 11:30:01 -0600
> From: "Rima Chaudhuri" <rima.chaudhuri_at_[hidden]>
> Subject: [OMPI users] Scyld Beowulf and openmpi
> To: users_at_[hidden]
> Message-ID:
> <7503b17d0811030930i13acb974kc627983a1d481192_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello!
> I am a new user of openmpi -- I've installed openmpi 1.2.6 for our
> x86_64 linux scyld beowulf cluster inorder to make it run with amber10
> MD simulation package.
>
> The nodes can see the home directory i.e. a bpsh to the nodes works
> fine and lists all the files in the home directory where I have both
> openmpi and amber10 installed.
> However if I try to run:
>
> $MPI_HOME/bin/mpirun -no_local=1 -np 4 $AMBERHOME/exe/sander.MPI ........
>
> I get the following error:
> [0,0,0] ORTE_ERROR_LOG: Not available in file ras_bjs.c at line 247
> --------------------------------------------------------------------------
> Failed to find the following executable:
>
> Host: helios.structure.uic.edu
> Executable: -o
>
> Cannot continue.
> --------------------------------------------------------------------------
> [helios.structure.uic.edu:23611] [0,0,0] ORTE_ERROR_LOG: Not found in
> file rmgr_urm.c at line 462
> [helios.structure.uic.edu:23611] mpirun: spawn failed with errno=-13
>
> any cues?
>
>
> --
> -Rima
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 3 Nov 2008 12:08:36 -0700
> From: Ralph Castain <rhc_at_[hidden]>
> Subject: Re: [OMPI users] Scyld Beowulf and openmpi
> To: Open MPI Users <users_at_[hidden]>
> Message-ID: <91044A7E-ADA5-4B94-AA11-B3C1D9843606_at_[hidden]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> For starters, there is no "-no_local" option to mpirun. You might want
> to look at mpirun --help, or man mpirun.
>
> I suspect the option you wanted was --nolocal. Note that --nolocal
> does not take an argument.
>
> Mpirun is confused by the incorrect option and looking for an
> incorrectly named executable.
> Ralph
>
>
> On Nov 3, 2008, at 10:30 AM, Rima Chaudhuri wrote:
>
>> Hello!
>> I am a new user of openmpi -- I've installed openmpi 1.2.6 for our
>> x86_64 linux scyld beowulf cluster inorder to make it run with amber10
>> MD simulation package.
>>
>> The nodes can see the home directory i.e. a bpsh to the nodes works
>> fine and lists all the files in the home directory where I have both
>> openmpi and amber10 installed.
>> However if I try to run:
>>
>> $MPI_HOME/bin/mpirun -no_local=1 -np 4 $AMBERHOME/exe/
>> sander.MPI ........
>>
>> I get the following error:
>> [0,0,0] ORTE_ERROR_LOG: Not available in file ras_bjs.c at line 247
>> --------------------------------------------------------------------------
>> Failed to find the following executable:
>>
>> Host: helios.structure.uic.edu
>> Executable: -o
>>
>> Cannot continue.
>> --------------------------------------------------------------------------
>> [helios.structure.uic.edu:23611] [0,0,0] ORTE_ERROR_LOG: Not found in
>> file rmgr_urm.c at line 462
>> [helios.structure.uic.edu:23611] mpirun: spawn failed with errno=-13
>>
>> any cues?
>>
>>
>> --
>> -Rima
>> _______________________________________________
>> users mailing list
>> users_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 3 Nov 2008 14:53:55 -0500
> From: "Gustavo Seabra" <gustavo.seabra_at_[hidden]>
> Subject: [OMPI users] Problems installing in Cygwin - Problem with GCC
> 3.4.4
> To: "Open MPI Users" <users_at_[hidden]>
> Message-ID:
> <f79359b60811031153l5591e0f8j49a7e4d9fb02eea3_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi everyone,
>
> Here's a "progress report"... more questions in the end :-)
>
> Finally, I was *almost* able to compile OpenMPI in Cygwin using the
> following configure command:
>
> ./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 \
> FC=g95 'FFLAGS=-O0 -fno-second-underscore' CXX=g++
>
> I then had a very weird error during compilation of
> ompi/tools/ompi_info/params.cc. (See below).
>
> The lines causing the compilation errors are:
>
> vector.tcc:307: const size_type __len = __old_size +
> std::max(__old_size, __n);
> vector.tcc:384: const size_type __len = __old_size +
> std::max(__old_size, __n);
> stl_bvector.h:522: const size_type __len = size() + std::max(size(), __n);
> stl_bvector.h:823: const size_type __len = size() + std::max(size(), __n);
>
> (Notice that those are from the standard gcc libraries.)
>
> After googling it for a while, I could find that this error is caused
> because, at come point, the source code being compiled redefined the
> "max" function with a macro, g++ cannot recognize the "std::max" that
> happens in those lines and only "sees" a (...), thus printing that
> cryptic complaint.
>
> I looked in some places in the OpenMPI code, but I couldn't find
> "max" being redefined anywhere, but I may be looking in the wrong
> places. Anyways, the only way of found of compiling OpenMPI was a very
> ugly hack: I have to go into those files and remove the "std::" before
> the "max". With that, it all compiled cleanly.
>
> I did try running the tests in the 'tests' directory (with 'make
> check'), and I didn't get any alarming message, except that in some
> cases (class, threads, peruse) it printed "All 0 tests passed". I got
> and "All (n) tests passed" (n>0) for asm and datatype.
>
> Can anybody comment on the meaning of those test results? Should I be
> alarmed with the "All 0 tests passed" messages?
>
> Finally, in the absence of big red flags (that I noticed), I went
> ahead and tried to compile my program. However, as soon as compilation
> starts, I get the following:
>
> /local/openmpi/openmpi-1.3b1/bin/mpif90 -c -O3 -fno-second-underscore
> -ffree-form -o constants.o _constants.f
> --------------------------------------------------------------------------
> Unfortunately, this installation of Open MPI was not compiled with
> Fortran 90 support. As such, the mpif90 compiler is non-functional.
> --------------------------------------------------------------------------
> make[1]: *** [constants.o] Error 1
> make[1]: Leaving directory `/home/seabra/local/amber11/src/sander'
> make: *** [parallel] Error 2
>
> Notice that I compiled OpenMPI with g95, so there *should* be
> Fortran95 support... Any ideas on what could be going wrong?
>
> Thank you very much,
> Gustavo.
>
> ======================================
> Error in the compilation of params.cc
> ======================================
> $ g++ -DHAVE_CONFIG_H -I. -I../../../opal/include
> -I../../../orte/include -I../../../ompi/include
> -I../../../opal/mca/paffinity/linux/plpa/src/libplpa
> -DOMPI_CONFIGURE_USER="\"seabra\"" -DOMPI_CONFIGURE_HOST="\"ACS02\""
> -DOMPI_CONFIGURE_DATE="\"Sat Nov 1 20:44:32 EDT 2008\""
> -DOMPI_BUILD_USER="\"$USER\"" -DOMPI_BUILD_HOST="\"`hostname`\""
> -DOMPI_BUILD_DATE="\"`date`\"" -DOMPI_BUILD_CFLAGS="\"-O3 -DNDEBUG
> -finline-functions -fno-strict-aliasing \""
> -DOMPI_BUILD_CPPFLAGS="\"-I../../.. -D_REENTRANT\""
> -DOMPI_BUILD_CXXFLAGS="\"-O3 -DNDEBUG -finline-functions \""
> -DOMPI_BUILD_CXXCPPFLAGS="\"-I../../.. -D_REENTRANT\""
> -DOMPI_BUILD_FFLAGS="\"-O0 -fno-second-underscore\""
> -DOMPI_BUILD_FCFLAGS="\"\"" -DOMPI_BUILD_LDFLAGS="\"-export-dynamic
> \"" -DOMPI_BUILD_LIBS="\"-lutil \""
> -DOMPI_CC_ABSOLUTE="\"/usr/bin/gcc\""
> -DOMPI_CXX_ABSOLUTE="\"/usr/bin/g++\""
> -DOMPI_F77_ABSOLUTE="\"/usr/bin/g77\""
> -DOMPI_F90_ABSOLUTE="\"/usr/local/bin/g95\""
> -DOMPI_F90_BUILD_SIZE="\"small\"" -I../../.. -D_REENTRANT -O3
> -DNDEBUG -finline-functions -MT param.o -MD -MP -MF $depbase.Tpo -c
> -o param.o param.cc
> In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/vector:72,
> from ../../../ompi/tools/ompi_info/ompi_info.h:24,
> from param.cc:43:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In
> member function `void std::vector<bool,
> _Alloc>::_M_insert_range(std::_Bit_iterator, _ForwardIterator,
> _ForwardIterator, std::forward_iterator_tag)':
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:522:
> error: expected unqualified-id before '(' token
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In
> member function `void std::vector<bool,
> _Alloc>::_M_fill_insert(std::_Bit_iterator, size_t, bool)':
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:823:
> error: expected unqualified-id before '(' token
> In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/vector:75,
> from ../../../ompi/tools/ompi_info/ompi_info.h:24,
> from param.cc:43:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In
> member function `void std::vector<_Tp,
> _Alloc>::_M_fill_insert(__gnu_cxx::__normal_iterator<typename
> _Alloc::pointer, std::vector<_Tp, _Alloc> >, size_t, const _Tp&)':
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:307:
> error: expected unqualified-id before '(' token
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In
> member function `void std::vector<_Tp,
> _Alloc>::_M_range_insert(__gnu_cxx::__normal_iterator<typename
> _Alloc::pointer, std::vector<_Tp, _Alloc> >, _ForwardIterator,
> _ForwardIterator, std::forward_iterator_tag)':
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:384:
> error: expected unqualified-id before '(' token
>
>
> --
> Gustavo Seabra
> Postdoctoral Associate
> Quantum Theory Project - University of Florida
> Gainesville - Florida - USA
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 3 Nov 2008 14:54:25 -0500
> From: Jeff Squyres <jsquyres_at_[hidden]>
> Subject: Re: [OMPI users] MPI + Mixed language coding(Fortran90 + C++)
> To: Open MPI Users <users_at_[hidden]>
> Message-ID: <45698801-0857-466F-A19D-C529F72D4A18_at_[hidden]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Can you replicate the scenario in smaller / different cases?
>
> - write a sample plugin in C instead of C++
> - write a non-MPI Fortran application that loads your C++ application
> - ...?
>
> In short, *MPI* shouldn't be interfering with Fortran/C++ common
> blocks. Try taking MPI out of the picture and see if that makes the
> problem go away.
>
> Those are pretty much shots in the dark, but I don't know where to go,
> either -- try random things until you find what you want.
>
>
> On Nov 3, 2008, at 3:51 AM, Rajesh Ramaya wrote:
>
>> Helllo Jeff, Gustavo, Mi
>> Thank for the advice. I am familiar with the difference in the
>> compiler code generation for C, C++ & FORTRAN. I even tried to look
>> at some of the common block symbols. The name of the symbol remains
>> the same. The only difference that I observe is in FORTRAN compiled
>> *.o 0000000000515bc0 B aux7loc_ and the C++ compiled code U
>> aux7loc_ the memory is not allocated as it has been declared as
>> extern in C++. When the executable loads the shared library it finds
>> all the undefined symbols. Atleast if it did not manage to find a
>> single symbol it prints undefined symbol error.
>> I am completely stuck up and do not know how to continue further.
>>
>> Thanks,
>> Rajesh
>>
>> From: users-bounces_at_[hidden] [mailto:users-bounces_at_[hidden]]
>> On Behalf Of Mi Yan
>> Sent: samedi 1 novembre 2008 23:26
>> To: Open MPI Users
>> Cc: 'Open MPI Users'; users-bounces_at_[hidden]
>> Subject: Re: [OMPI users] MPI + Mixed language coding(Fortran90 + C++)
>>
>> So your tests show:
>> 1. "Shared library in FORTRAN + MPI executable in FORTRAN" works.
>> 2. "Shared library in C++ + MPI executable in FORTRAN " does not work.
>>
>> It seems to me that the symbols in C library are not really
>> recognized by FORTRAN executable as you thought. What compilers did
>> yo use to built OpenMPI?
>>
>> Different compiler has different convention to handle symbols. E.g.
>> if there is a variable "var_foo" in your FORTRAN code, some FORTRN
>> compiler will save "var_foo_" in the object file by default; if you
>> want to access "var_foo" in C code, you actually need to refer
>> "var_foo_" in C code. If you define "var_foo" in a module in the
>> FORTAN compiler, some FORTRAN compiler may append the module name to
>> "var_foo".
>> So I suggest to check the symbols in the object files generated by
>> your FORTAN and C compiler to see the difference.
>>
>> Mi
>> <image001.gif>"Rajesh Ramaya" <rajesh.ramaya_at_[hidden]>
>>
>>
>> "Rajesh Ramaya" <rajesh.ramaya_at_[hidden]>
>> Sent by: users-bounces_at_[hidden]
>> 10/31/2008 03:07 PM
>>
>> Please respond to
>> Open MPI Users <users_at_[hidden]>
>> <image002.gif>
>> To
>> <image003.gif>
>> "'Open MPI Users'" <users_at_[hidden]>, "'Jeff Squyres'" <jsquyres_at_[hidden]
>> >
>> <image002.gif>
>> cc
>> <image003.gif>
>> <image002.gif>
>> Subject
>> <image003.gif>
>> Re: [OMPI users] MPI + Mixed language coding(Fortran90 + C++)
>>
>> <image003.gif>
>> <image003.gif>
>>
>> Hello Jeff Squyres,
>> Thank you very much for the immediate reply. I am able to
>> successfully
>> access the data from the common block but the values are zero. In my
>> algorithm I even update a common block but the update made by the
>> shared
>> library is not taken in to account by the executable. Can you please
>> be very
>> specific how to make the parallel algorithm aware of the data?
>> Actually I am
>> not writing any MPI code inside? It's the executable (third party
>> software)
>> who does that part. All that I am doing is to compile my code with
>> MPI c
>> compiler and add it in the LD_LIBIRARY_PATH.
>> In fact I did a simple test by creating a shared library using a
>> FORTRAN
>> code and the update made to the common block is taken in to account
>> by the
>> executable. Is there any flag or pragma that need to be activated
>> for mixed
>> language MPI?
>> Thank you once again for the reply.
>>
>> Rajesh
>>
>> -----Original Message-----
>> From: users-bounces_at_[hidden] [mailto:users-bounces_at_[hidden]]
>> On
>> Behalf Of Jeff Squyres
>> Sent: vendredi 31 octobre 2008 18:53
>> To: Open MPI Users
>> Subject: Re: [OMPI users] MPI + Mixed language coding(Fortran90 + C++)
>>
>> On Oct 31, 2008, at 11:57 AM, Rajesh Ramaya wrote:
>>
>> > I am completely new to MPI. I have a basic question concerning
>> > MPI and mixed language coding. I hope any of you could help me out.
>> > Is it possible to access FORTRAN common blocks in C++ in a MPI
>> > compiled code. It works without MPI but as soon I switch to MPI the
>> > access of common block does not work anymore.
>> > I have a Linux MPI executable which loads a shared library at
>> > runtime and resolves all undefined symbols etc The shared library
>> > is written in C++ and the MPI executable in written in FORTRAN. Some
>> > of the input that the shared library looking for are in the Fortran
>> > common blocks. As I access those common blocks during runtime the
>> > values are not initialized. I would like to know if what I am
>> > doing is possible ?I hope that my problem is clear......
>>
>>
>> Generally, MPI should not get in the way of sharing common blocks
>> between Fortran and C/C++. Indeed, in Open MPI itself, we share a few
>> common blocks between Fortran and the main C Open MPI implementation.
>>
>> What is the exact symptom that you are seeing? Is the application
>> failing to resolve symbols at run-time, possibly indicating that
>> something hasn't instantiated a common block? Or are you able to
>> successfully access the data from the common block, but it doesn't
>> have the values you expect (e.g., perhaps you're seeing all zeros)?
>>
>> If the former, you might want to check your build procedure. You
>> *should* be able to simply replace your C++ / F90 compilers with
>> mpicxx and mpif90, respectively, and be able to build an MPI version
>> of your app. If the latter, you might need to make your parallel
>> algorithm aware of what data is available in which MPI process --
>> perhaps not all the data is filled in on each MPI process...?
>>
>> --
>> Jeff Squyres
>> Cisco Systems
>>
>>
>> _______________________________________________
>> users mailing list
>> users_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>
>> _______________________________________________
>> users mailing list
>> users_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>
>> _______________________________________________
>> users mailing list
>> users_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>
>
> --
> Jeff Squyres
> Cisco Systems
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 3 Nov 2008 15:04:47 -0500
> From: Jeff Squyres <jsquyres_at_[hidden]>
> Subject: Re: [OMPI users] Problems installing in Cygwin - Problem with
> GCC 3.4.4
> To: Open MPI Users <users_at_[hidden]>
> Message-ID: <8E364B51-6726-4533-ADE2-AEA266380DCC_at_[hidden]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> On Nov 3, 2008, at 2:53 PM, Gustavo Seabra wrote:
>
>> Finally, I was *almost* able to compile OpenMPI in Cygwin using the
>> following configure command:
>>
>> ./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 \
>> FC=g95 'FFLAGS=-O0 -fno-second-underscore' CXX=g++
>
> For your fortran issue, the Fortran 90 interface needs the Fortran 77
> interface. So you need to supply an F77 as well (the output from
> configure should indicate that the F90 interface was disabled because
> the F77 interface was disabled).
>
>> I then had a very weird error during compilation of
>> ompi/tools/ompi_info/params.cc. (See below).
>>
>> The lines causing the compilation errors are:
>>
>> vector.tcc:307: const size_type __len = __old_size +
>> std::max(__old_size, __n);
>> vector.tcc:384: const size_type __len = __old_size +
>> std::max(__old_size, __n);
>> stl_bvector.h:522: const size_type __len = size() +
>> std::max(size(), __n);
>> stl_bvector.h:823: const size_type __len = size() +
>> std::max(size(), __n);
>>
>> (Notice that those are from the standard gcc libraries.)
>>
>> After googling it for a while, I could find that this error is caused
>> because, at come point, the source code being compiled redefined the
>> "max" function with a macro, g++ cannot recognize the "std::max" that
>> happens in those lines and only "sees" a (...), thus printing that
>> cryptic complaint.
>>
>> I looked in some places in the OpenMPI code, but I couldn't find
>> "max" being redefined anywhere, but I may be looking in the wrong
>> places. Anyways, the only way of found of compiling OpenMPI was a very
>> ugly hack: I have to go into those files and remove the "std::" before
>> the "max". With that, it all compiled cleanly.
>
> I'm not sure I follow -- I don't see anywhere in OMPI where we use
> std::max. What areas did you find that you needed to change?
>
>> I did try running the tests in the 'tests' directory (with 'make
>> check'), and I didn't get any alarming message, except that in some
>> cases (class, threads, peruse) it printed "All 0 tests passed". I got
>> and "All (n) tests passed" (n>0) for asm and datatype.
>>
>> Can anybody comment on the meaning of those test results? Should I be
>> alarmed with the "All 0 tests passed" messages?
>
> No. We don't really maintain the "make check" stuff too well.
>
> --
> Jeff Squyres
> Cisco Systems
>
>
>
> ------------------------------
>
> _______________________________________________
> users mailing list
> users_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>
> End of users Digest, Vol 1055, Issue 2
> **************************************
>

-- 
-Rima


  • application/octet-stream attachment: step1