Re: PetSc

[Adam C Powell IV <hazelsct@mit.edu>]

Junichi Uekawa wrote:

> In 12 Jan 2001 11:23:53 -0500 Camm Maguire <camm@enhanced.com> cum veritate scripsit :
>
> > My understanding is that the most recent lam's mpirun can take the
> > same syntax as mpich's, though it has additional options as well.
> > Could be mistaken on this, as am not too familiar with mpich.
>
> I think things are compatible as far as
>
> mpirun -np #machines programname
>
> is concerned ... and I guess that's the most important bit.

Very cool, that would eliminate the need for PETSc's mpirun.lam, which is attached.  Or
do the other lam options in that script make a difference?

> > > > Oh- and mpich doesn't have shared libs, so when you link -mpi
> > > > and
> > > > /etc/alternatives points to mpich, there are dangling symlinks for
> > > > libmpi.so. :-(
> > > Actually it is possible to build shared library for mpich, and
> > > I tried it. It was not very exciting.
> > Not too exciting?  Sounds like real progress to me!  Is the latest
> > mpich package equipped with these shared libs?=
>
> The latest version does not have support for shared lib support built.
> There is an option to build a shared lib, but I couldn't make it
> really work.

That's too bad.  Oh well, until there's a shared lib, there's bug #82038.

> > Meanwhile, I've been discussing the binary compatibility issue with
> > the lam authors, and it may not be quite as difficult as we had
> > thought, (only if both implementations use shared libs, of course).
> > Even if this were achieved, we'd have a Debian problem:  with the
> > alternatives scheme, compiling against -lmpi will produce a binary
> > with ldd reporting linkage against liblam or libmpich -- the compiler
> > goes straight through the symbolic links.

Not exactly, it goes to the soname.

> Maybe this can be handled
> > with a compiler/linker flag, but otherwise, we'd have to fall back on
> > diversions (e.g. dpkg-divert) for libmpi.
>
> Hmm... diversions are evil. Okay, let's see what could be done.
> But first, I've gotta get shared libs version compiled.

Wow, never heard of them.  Well, for now PETSc will build with and depend on a default
implementation (tentatively mpich for now, unless Eray's benchmarks are very convincing;
I plan to do some benchmarking too :-), and within a week or so I should have -3 up with
a compile-time option to build with and depend on the non-default.  And maybe some
different binary package names, possibly with compiler and/or MPI implementation in
them...

Thanks,

-Adam P.

                  Welcome to the best software in the world today cafe!

#!/bin/sh
#set -x

#
# This program is a wrapper over lam's mpirun. It converts
# the mpich's mpirun formated command to lam's format.
# and invokes lam's mpirun with it.
#

if [ $1 !=  "-np" ]; then
echo "Error in  mpirun command"
exit 1
fi
shift
np=$1
shift
progname=$1
shift
options=$*
#
# Please modify the following path to point to the correct location of LAM's mpirun
#
lam_path=/usr/bin
#
# Now execute the mpirun comman
#
$lam_path/mpirun_lam -w -c $np -s n0 $progname -- $options
$lam_path/lamclean