Using the modules software (modules.sourceforge.net) works pretty
well for managing multiple mpi flavors. You still need to put each
mpi flavor's bin, lib, and include files in uniquely named paths,
then modules lets you put the appropriate mpi flavor in your path for
each application. It takes a little effort to set modules up but then
it is easy to use. It is particularly helpful for users who aren't
good at editing .xxrc files.
On Apr 25, 2008, at 8:46 AM, Jeff Squyres wrote:
> On Apr 25, 2008, at 10:54 AM, Hans Wurst wrote:
>>> So you'll need to
>>> compile your benchmarks for each MPI implementation that you want to
>>> test (i.e., use that MPI's wrapper compilers to compile them).
>> I'm not conscious about what a MPI wrapper compiler is and how it
> mpicc (et al.) are the "wrapper" compilers. So you compile your app
> mpicc my_mpi_app.c -o my_mpi_app
> All the "wrapper" compilers do is add in the relevant compiler /
> linker flags and invoke the underlying compiler. See:
>> Maybe we can discuss this with a little example:
>> mpptest requires the current installation path of the MPI-
>> implementation before compiling. When I switch between MPI-
>> implementations, do I have to re-compile the benchmark each time? If
>> not, how do I handle that issue? How do I keep the two compiled
>> executables separate?
> In general, yes, you need to have different executables for each MPI
> implementation (likely compiled with their wrapper compilers, or
> whatever compiler/linker flags may be required for that MPI
> I don't recall mpptest's build system offhand; a simple solution would
> be to have multiple copies of the mpptest software and build them each
> for a single MPI implementation.
> Another option is to build for one, rename the output exectuable
> (E.g., "mv mpptest mpptest.openmpi"), and then repeat as desired.
>>> The --prefix option (and friends) make the ssh/rsh command line much
>>> more complex, effectively setting PATH and LD_LIBRARY_PATH for
>>> you on
>>> each remote machine before launching orted.
>> OK, I tried that and it works great. Knowing that, I've got one more
>> question regarding different MPI-Implementations on one node. What
>> is the smartest way to switch between them?
>> Changing the PATH's in the .bashrc and rebooting the nodes? Is there
>> a smart way to do that online without reboot? Would it be possible
>> to have two separate users "MPICHuser" and "OpenMPIuser" each with
>> the PATH for the corresponding MPI-implementation´, and launching
>> the processes for the different implementations with these separate
> No, you likely don't need anything so elaborate (at least for Open
> If you use the full/absolute path name to Open MPI, it'll effect
> the --
> prefix functionality for you. Keep in mind that --prefix
> functionality means that you don't need any setup on the remote node
> (nothing in your .bashrc, etc.). So you can:
> /path/to/first/openmpi/bin/mpirun ....
> /path/to/second/openmpi/bin/mpirun ....
> This will use the two different Open MPI installations. Or, if you
> use the --enable-mpirun-prefix-by-default option when configuring/
> building Open MPI, then you can use something like environment modules
> to switch between different MPI implementations (http://
> modules.sf.net/) and set them in your PATH. Then just [Open MPI's]
> "mpirun" will do the Right thing by default, perhaps something like
> module load openmpi/1.2.5
> mpirun ....
> module unload openmpi
> module load openmpi/1.2.6
> mpirun ....
> And so on.
> For MPICH, I don't know exactly what they require in terms of remote
> path setup, etc. I don't know if it has --prefix like functionality,
> or if it automatically does it (like OMPI's --enable-mpirun-prefix-by-
> default), etc. You'll need to check their docs.
> Jeff Squyres
> Cisco Systems
> users mailing list