MPI implementations in squeeze

[Nicholas Breen]

With the recent upload of MPICH2, we now have four separate MPI implementations
in the archive: two with active upstreams and maintainers (MPICH2, OpenMPI) and
two on terminal life support (MPICH, LAM).

There's been some preliminary discussion before about dropping the latter two
[1], though legacy support is an issue as well [2].  Currently, the MPI
situation is fairly messy: 18 source packages depend on mpi-default-dev
(OpenMPI or LAM, depending on architecture), but another 18 depend on various
permutations of the implementations directly [3], with no particular
consistency.

>From a package maintainer standpoint, I'd like to see us start reducing the
number of implementations to build client packages against, even if we maintain
all the MPI implementations themselves (perhaps moving them to the 'oldlibs'
section).  What I'm wondering is:

 * in mpi-defaults, should MPICH2 replace LAM for architectures not supported
   by OpenMPI?
 * should we start filing wishlist bugs asking packagers not to build against
   MPICH (1) and LAM?
 * is it too late in the release cycle to propose this as a release goal?
   should squeeze+1 be the target instead?  squeeze+2?

This is orthogonal to solving #552429, which will need action before the
squeeze release in any case.


--
Nicholas Breen
nbreen@...


[1] http://lists.debian.org/debian-science/2009/06/msg00029.html
[2] http://lists.debian.org/debian-science/2009/06/msg00039.html
[3] build-deps on:      lam4-dev        libmpich1.0-dev libopenmpi-dev
      apbs              no              yes             yes
      clustalw-mpi      yes             no              yes
      ecs               no              no              yes
      fftw              no              yes             no
      gromacs           yes             yes             yes
      hpcc              no              no              yes
      hdf5              yes             yes             yes
      meep              no              yes             no
      mpb               no              yes             no
      music             no              no              yes
      netpipe           yes             yes             no
      python-scientific yes             yes             no
      regina-normal     no              yes             no
      tessa             yes             no              no
      tree-puzzle       yes             no              no
      trilinos          no              no              yes
      xmds              no              yes             no
      xmpi              yes             no              no


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

On Mon, Nov 09, 2009 at 04:47:27PM -0800, Nicholas Breen wrote:
> [3] build-deps on:      lam4-dev        libmpich1.0-dev libopenmpi-dev
> ...
>       tree-puzzle       yes             no              no

Just uploaded tree-puzzle builded agianst libopenmpi-dev.

Kind regards

       Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Adam C Powell IV]

Here are my opinions for what they're worth...

On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote:
> There's been some preliminary discussion before about dropping the latter two
> [1], though legacy support is an issue as well [2].  Currently, the MPI
> situation is fairly messy: 18 source packages depend on mpi-default-dev
> (OpenMPI or LAM, depending on architecture), but another 18 depend on various
> permutations of the implementations directly [3], with no particular
> consistency.

The concerns you raise are the motivation for mpi-defaults.  And IMO 50%
voluntary transition there with no particular push or strong impetus is
pretty good progress.

> >From a package maintainer standpoint, I'd like to see us start reducing the
> number of implementations to build client packages against, even if we maintain
> all the MPI implementations themselves (perhaps moving them to the 'oldlibs'
> section).  What I'm wondering is:
>
>  * in mpi-defaults, should MPICH2 replace LAM for architectures not supported
>    by OpenMPI?

I think that would make a lot of sense since LAM is end-of-life.

>  * should we start filing wishlist bugs asking packagers not to build against
>    MPICH (1) and LAM?

I've done this for packages I care about, and posted patches, and done
NMUs (with maintainer approval).  So I'd say go for it.

>  * is it too late in the release cycle to propose this as a release goal?
>    should squeeze+1 be the target instead?  squeeze+2?

I think it's too late for squeeze, but squeeze+1 should definitely be
doable.

> This is orthogonal to solving #552429, which will need action before the
> squeeze release in any case.

Indeed.  And while we're at it, given the popularity of fortran, we need
a consistent fortran library alternatives link as a slave of mpi...
Will add that to the bug.

-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

[Michael Banck]

On Tue, Nov 10, 2009 at 09:19:11AM -0500, Adam C Powell IV wrote:
> On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote:
> >  * is it too late in the release cycle to propose this as a release goal?
> >    should squeeze+1 be the target instead?  squeeze+2?
>
> I think it's too late for squeeze, but squeeze+1 should definitely be
> doable.

How many packages are affected?  Squeeze freeze is several months away
still.  I am not sure about release-goal freeze, but even then, it could
be considered an inofficial release goal among debian-science at least.


Michael


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Adam C Powell IV]

On Tue, 2009-11-10 at 16:27 +0100, Michael Banck wrote:
> On Tue, Nov 10, 2009 at 09:19:11AM -0500, Adam C Powell IV wrote:
> > On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote:
> > >  * is it too late in the release cycle to propose this as a release goal?
> > >    should squeeze+1 be the target instead?  squeeze+2?
> >
> > I think it's too late for squeeze, but squeeze+1 should definitely be
> > doable.
>
> How many packages are affected?

I think your previous email best answered that question.

> Squeeze freeze is several months away
> still.  I am not sure about release-goal freeze, but even then, it could
> be considered an inofficial release goal among debian-science at least.

Oh, right.  For some reason my mental calendar still has late '09 as the
release goal date.  I'm all for it then, at least unofficially.

The other issue would be rebuilding all of the mpi-defaults packages at
least on lam architectures when/if we decide to switch to mpich2.  Count
my vote in support of such a switch, which might be worth as much as
$0.03-.04 since I wrote the original mpi-defaults. :-)

-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

[Manuel Prinz-3]

First of all: Thanks, Nicholas, for bringing it up and providing the
very helpful information!

> On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote:
> > There's been some preliminary discussion before about dropping the latter two
> > [1], though legacy support is an issue as well [2].  Currently, the MPI
> > situation is fairly messy: 18 source packages depend on mpi-default-dev
> > (OpenMPI or LAM, depending on architecture), but another 18 depend on various
> > permutations of the implementations directly [3], with no particular
> > consistency.

Am Dienstag, den 10.11.2009, 09:19 -0500 schrieb Adam C Powell IV:
> The concerns you raise are the motivation for mpi-defaults.  And IMO 50%
> voluntary transition there with no particular push or strong impetus is
> pretty good progress.

I also think that mpi-defaults was a step in the right direction which
we should continue.

> > >From a package maintainer standpoint, I'd like to see us start reducing the
> > number of implementations to build client packages against, even if we maintain
> > all the MPI implementations themselves (perhaps moving them to the 'oldlibs'
> > section).  What I'm wondering is:
> >
> >  * in mpi-defaults, should MPICH2 replace LAM for architectures not supported
> >    by OpenMPI?
>
> I think that would make a lot of sense since LAM is end-of-life.

This might make sense. It's confusing that we have different
implementations on these platforms anyway, so having just supported
implementations seems like a plus to me.

> >  * should we start filing wishlist bugs asking packagers not to build against
> >    MPICH (1) and LAM?
>
> I've done this for packages I care about, and posted patches, and done
> NMUs (with maintainer approval).  So I'd say go for it.

This would help to bring the issue forward. I support this and offer
help where needed. But we should think of some preconditions before we
go with that. From the top of my head, these things need to be done:

      * Modify mpi-defaults to use MPICH2 on arches that are not
        supported by Open MPI (yet). This requires a rebuild of all
        dependant packages and needs to be coordinated with RM.
      * Bugs should be filed against all packages using the "obsolete"
        MPI implementations (LAM and MPICH1), requesting to drop the
        B-D. Severity minor or wishlist seem appropriate.
      * We should discuss whether or not we want to build packages
        against both MPI implementations or just mpi-defaults. Of course
        it is up to the maintainer to support as many implementations as
        time permits but I can imagine that users do not really care.
        They want to run an application in parallel, don't they? (I
        seriously don't know. Both approaches have their advantages.)
      * Alternatives need to be fixed. Besides what the bugs that
        Nicholas referenced say, there are two other issues with those:
        First, the priorities do not match the reality (Open MPI being
        the default / recommended implementation to use), and second,
        that mpi.so is also in the alternatives, which is wrong in every
        respect and has bother me for a very long time now. The
        implementations are not ABI-compatible in any way, and we really
        need to get rid of that. I have to check what needs to be done
        and if rebuilds are needed more closely. I will comment on the
        BTS on that.

The next steps pretty much depends on the answer to the question if we
want to support packages build against Open MPI and MPICH2 or just
recommend using mpi-defaults. Both have advantages, both have drawbacks.
And if we go for the first option, what is the correct behavior? Should
the packages conflict with each other or should they conflict with the
other library? Or should the be build in a way so that they can be
switched via alternatives as well? I have no idea what is reasonable,
but if we support more than one MPI implementation, we have should solve
that issue as well. The current practise is that every maintainer
decides what's best, and it's far from being ideal, IMHO. Don't get me
wrong: I do not think that maintainers did a bad job, quite the
opposite, but I think we now have the chance to fix structures that just
grew into what is the current situation, and that are in real need to be
fixed.

> >  * is it too late in the release cycle to propose this as a release goal?
> >    should squeeze+1 be the target instead?  squeeze+2?
>
> I think it's too late for squeeze, but squeeze+1 should definitely be
> doable.

As you said in your other mail, with the release date being somewhere in
the next year, this should be doable. If it's too late for a release
goal, we can make it an internal release goal. Arguments for that change
are reasonable and I guess that there is support on the maintainer side,
even if we can't make the bugs to be filed RC.

> > This is orthogonal to solving #552429, which will need action before the
> > squeeze release in any case.
>
> Indeed.  And while we're at it, given the popularity of fortran, we need
> a consistent fortran library alternatives link as a slave of mpi...
> Will add that to the bug.

This will be the first thing to fix, along with the library issue I
mentioned above. I'll start with that just now. ;)

Best regards
Manuel

[Manuel Prinz-3]

Am Dienstag, den 10.11.2009, 09:19 -0500 schrieb Adam C Powell IV:
> >  * in mpi-defaults, should MPICH2 replace LAM for architectures not supported
> >    by OpenMPI?
>
> I think that would make a lot of sense since LAM is end-of-life.

Filed as bug #555653, so we won't forget about that. We should wait with
the fix when the dust has settled. (Both here and with the big
transitions going on at the moment.)

Best regards
Manuel



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Adam C Powell IV]

I generally agree, just a quick nit-pick/clarification:

On Tue, 2009-11-10 at 20:56 +0100, Manuel Prinz wrote:
>       * Alternatives need to be fixed. Besides what the bugs that
>         Nicholas referenced say, there are two other issues with those:
>         First, the priorities do not match the reality (Open MPI being
>         the default / recommended implementation to use), and second,
>         that mpi.so is also in the alternatives, which is wrong in every
>         respect and has bother me for a very long time now. The
>         implementations are not ABI-compatible in any way, and we really
>         need to get rid of that.

The .so alternatives symlinks only require that the libraries be
API-compatible, which they are (or if not, it's a bug, since they're
supposed to follow the MPI standard).  That's why these links, and
plain .so links in general, are in the -dev packages, not the shlib
packages.  It should be possible to compile any MPI program's source
code against any implementation by linking -lmpi -lmpi++ etc.

Then the resulting binary, shlib etc. includes the soname specific to
the library it linked with, e.g. libopen-rte.so.0 .  So if it's in a
Debian package, the resulting binary depends on the ABI-correct library
package, e.g. libopenmpi1 .

If this still doesn't make sense, the libtool online documentation is
pretty clear.

-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

[Manuel Prinz-3]

Gee, I should stop posting past a certain hour of the day… ;)

On Tue, 2009-11-10 at 18:08 -0500, Adam C Powell IV wrote:

> The .so alternatives symlinks only require that the libraries be
> API-compatible, which they are (or if not, it's a bug, since they're
> supposed to follow the MPI standard).  That's why these links, and
> plain .so links in general, are in the -dev packages, not the shlib
> packages.  It should be possible to compile any MPI program's source
> code against any implementation by linking -lmpi -lmpi++ etc.
>
> Then the resulting binary, shlib etc. includes the soname specific to
> the library it linked with, e.g. libopen-rte.so.0 .  So if it's in a
> Debian package, the resulting binary depends on the ABI-correct library
> package, e.g. libopenmpi1 .

You're of course right. I somehow mixed several things up and got quite
confused. Open MPI indeed does use libmpi.so.0 for the name, all other
implementations don't. I probably mixed libmpi.so and libmpi.so.0 here,
among other things. (Though this is not really an issue, it might be
nice to build it as libopenmpi.so.0 or something.)

> If this still doesn't make sense, the libtool online documentation is
> pretty clear.

Now, awake and conscious, it makes perfect sense. The libtool doc is a
good read, nevertheless. Sorry for the noise! You're "nitpicking", as
you called it, was very welcome! :)

Best regards
Manuel


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Drew Parsons]

I understand the final state of the modern Debian infrastructure for MPI
is now in place (modulo the questions around deprecating MPICH and LAM).
That is, the disruptive Open MPI transition is now complete, correct?

>From the point of view of a client package, what is now best practice
for working with MPI?  Is there a website/wiki/document explaining how
to set up an MPI-using package, or is it just a matter of RTFM from
mpi-default-dev?

For context, gerris includes MPI support which is currently switched
off. I would like to create an additional gerris-mpi package which has
MPI switched on.

Thanks,

Drew


On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote:

> With the recent upload of MPICH2, we now have four separate MPI implementations
> in the archive: two with active upstreams and maintainers (MPICH2, OpenMPI) and
> two on terminal life support (MPICH, LAM).
>
> There's been some preliminary discussion before about dropping the latter two
> [1], though legacy support is an issue as well [2].  Currently, the MPI
> situation is fairly messy: 18 source packages depend on mpi-default-dev
> (OpenMPI or LAM, depending on architecture), but another 18 depend on various
> permutations of the implementations directly [3], with no particular
> consistency.
>
> >From a package maintainer standpoint, I'd like to see us start reducing the
> number of implementations to build client packages against, even if we maintain
> all the MPI implementations themselves (perhaps moving them to the 'oldlibs'
> section).  What I'm wondering is:
>
>  * in mpi-defaults, should MPICH2 replace LAM for architectures not supported
>    by OpenMPI?
>  * should we start filing wishlist bugs asking packagers not to build against
>    MPICH (1) and LAM?
>  * is it too late in the release cycle to propose this as a release goal?
>    should squeeze+1 be the target instead?  squeeze+2?
>
> This is orthogonal to solving #552429, which will need action before the
> squeeze release in any case.
>

--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Nicholas Breen]

On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
> I understand the final state of the modern Debian infrastructure for MPI
> is now in place (modulo the questions around deprecating MPICH and LAM).
> That is, the disruptive Open MPI transition is now complete, correct?

Yes, so far as I know.  There might be the occasional need for a binNMU as
MPICH2 settles in and if mpi-default-dev switches to MPICH2 instead of LAM as
the backup, but those shouldn't interfere with testing migration.

> >From the point of view of a client package, what is now best practice
> for working with MPI?  Is there a website/wiki/document explaining how
> to set up an MPI-using package, or is it just a matter of RTFM from
> mpi-default-dev?
>
> For context, gerris includes MPI support which is currently switched
> off. I would like to create an additional gerris-mpi package which has
> MPI switched on.

No particular documentation that I'm aware of, though it's a good thought....

If you just want one MPI package, it should be enough to Build-Depend on
mpi-default-dev and perform a build of your package with whatever flags are
necessary -- which ideally should be something simple like "configure
--enable-mpi CC=mpicc".



--
Nicholas Breen
nbreen@...


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manuel Prinz-3]

Am Montag, den 30.11.2009, 22:11 -0800 schrieb Nicholas Breen:

> On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
> > From the point of view of a client package, what is now best practice
> > for working with MPI?  Is there a website/wiki/document explaining how
> > to set up an MPI-using package, or is it just a matter of RTFM from
> > mpi-default-dev?
> >
> > For context, gerris includes MPI support which is currently switched
> > off. I would like to create an additional gerris-mpi package which has
> > MPI switched on.
>
> No particular documentation that I'm aware of, though it's a good thought....

I'm also not aware of that and really might be reasonable to write such
a document. It seems to me that there has been no or not much
cooperation of maintainers of MPI packages, which is changing at the
moment and works out well. I'm really happy about that! So chances for
MPI guidelines are good.

But adding MPI support is usually as easy as Nicholas pointed out in his
email. If one only wants to build an MPI version, build-depending on
mpi-default-dev is best; if you want to build one package per MPI
implementation, you have to do that yourself. Nicholas' gromacs package
is a good example for that!

Best regards
Manuel


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manuel Prinz-3]

Am Montag, den 09.11.2009, 16:47 -0800 schrieb Nicholas Breen:
>  * should we start filing wishlist bugs asking packagers not to build against
>    MPICH (1) and LAM?

If noone objects by the end of the week, I will file the bugs then. The
number of affected packages is really low and the severity wishlist, so
I guess we do not need to go through the usual MBF hassle, or do we?

Best regards
Manuel


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 01/12/09 at 11:33 +0100, Manuel Prinz wrote:
> Am Montag, den 09.11.2009, 16:47 -0800 schrieb Nicholas Breen:
> >  * should we start filing wishlist bugs asking packagers not to build against
> >    MPICH (1) and LAM?
>
> If noone objects by the end of the week, I will file the bugs then. The
> number of affected packages is really low and the severity wishlist, so
> I guess we do not need to go through the usual MBF hassle, or do we?

So the plan would be to use OpenMPI on all architectures where it is
supported, and MPICH2 on the other ones, using mpi-default?

What do we do with LAM and mpich1? Target their removal for squeeze?

While I would be fine with that, there are other possible plans:
(2) use MPICH2 as default everywhere (it is supported on all release
    archs). Clearly, the package didn't receive a lot of testing yet,
    but this is likely to be only a temporary problem.
(3) encourage people to provide packages for both MPICH2 and OpenMPI
    (where possible, or only MPICH2 if OpenMPI not possible).
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sylvestre Ledru-6]

Le mardi 01 décembre 2009 à 21:20 +0100, Lucas Nussbaum a écrit :

> On 01/12/09 at 11:33 +0100, Manuel Prinz wrote:
> > Am Montag, den 09.11.2009, 16:47 -0800 schrieb Nicholas Breen:
> > >  * should we start filing wishlist bugs asking packagers not to build against
> > >    MPICH (1) and LAM?
> >
> > If noone objects by the end of the week, I will file the bugs then. The
> > number of affected packages is really low and the severity wishlist, so
> > I guess we do not need to go through the usual MBF hassle, or do we?
>
> So the plan would be to use OpenMPI on all architectures where it is
> supported, and MPICH2 on the other ones, using mpi-default?

To me, this would be the best solution.

We could do the third proposal (build for both MPICH2 & OpenMPI) but, at
least to me, it complexifies the build process to have to handle many
different MPI implementations for a low gain for the lambda user.

Sylvestre



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Francesco P. Lovergine-3]

On Tue, Dec 01, 2009 at 11:31:02AM +0100, Manuel Prinz wrote:

> Am Montag, den 30.11.2009, 22:11 -0800 schrieb Nicholas Breen:
> > On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
> > > From the point of view of a client package, what is now best practice
> > > for working with MPI?  Is there a website/wiki/document explaining how
> > > to set up an MPI-using package, or is it just a matter of RTFM from
> > > mpi-default-dev?
> > >
> > > For context, gerris includes MPI support which is currently switched
> > > off. I would like to create an additional gerris-mpi package which has
> > > MPI switched on.
> >
> > No particular documentation that I'm aware of, though it's a good thought....
>
> I'm also not aware of that and really might be reasonable to write such
> a document. It seems to me that there has been no or not much
> cooperation of maintainers of MPI packages, which is changing at the
> moment and works out well. I'm really happy about that! So chances for
> MPI guidelines are good.
>
> But adding MPI support is usually as easy as Nicholas pointed out in his
> email. If one only wants to build an MPI version, build-depending on
> mpi-default-dev is best; if you want to build one package per MPI
> implementation, you have to do that yourself. Nicholas' gromacs package
> is a good example for that!
>

Nice to see things are going on. A policy document would be nice indeed,
with possibly use cases. Note that currently also hdf5 builds for
different MPI flavors with some specific hacks.

--
Francesco P. Lovergine


--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manuel Prinz-3]

Am Dienstag, den 01.12.2009, 21:20 +0100 schrieb Lucas Nussbaum:
> So the plan would be to use OpenMPI on all architectures where it is
> supported, and MPICH2 on the other ones, using mpi-default?

Yes.

> What do we do with LAM and mpich1? Target their removal for squeeze?

No, I would like to keep them for another release cycle so our users
have time to migrate. Removing all build-depends to them would be the
goal for squeeze, and a note in the release notes might be reasonable.
The removal could easily be done after squeeze.

On the other hand, they are not in the best shape, so this might be a
reason for them to go earlier. But it has been like that for quite a
while now, and a smooth transition might serve our users better. But I
really can't say what our users will prefer. Any input is very welcome!

> While I would be fine with that, there are other possible plans:
> (2) use MPICH2 as default everywhere (it is supported on all release
>     archs). Clearly, the package didn't receive a lot of testing yet,
>     but this is likely to be only a temporary problem.

I do not care that much. We chose Open MPI because it was the most
mature implementation at that time. I do not know much about MPICH2, and
am open to use MPICH2 as the default. I'd like to go with Open MPI, but
as one of the Open MPI maintainers in Debian, my view is biased. There
are some things that came into my mind:

      * We shipped with Open MPI in the last release. This is no strong
        argument, as the situation is still messy and we only had one
        reasonable choice. I'm for switching if there is a good
        technical argument about one over the other. If there isn't, I'd
        prefer to stay with it as is.
      * Open MPI does not build everywhere but it's well tested on the
        platforms where it builds, and shown to work as expected. From
        my experience LAM did build everywhere but did not run
        everywhere. I do not know about the situation with MPICH2. If
        it's functional on all platforms, it might be a good
        alternative.
      * The next upload of Open MPI will (probably) build on hppa. I
        have worked with upstream and other contributors to add support
        for other platforms, and we're working on more. For those not
        supported, we plan to build using libatomic-ops. I'm not sure
        when this will be done but I'm putting quite some efforts into
        that so we will have that for squeeze. Also no strong argument,
        I know.
      * Upstream is very active and supportive. Response time is low and
        all patches where included so far. They even coordinated a
        release with us. It helped us a lot. Again, might be the same
        with MPICH2, I just don't know.

Neither of those are strong arguments. I did not really want to argue,
anyway. The point was to get you all informed about what is going on on
the Open MPI side, as this is not really transparent most of the time.
If the situation with MPICH2 is similar to that of Open MPI, I'll not
object to use MPICH2 as the default. We should support our users by
enabling them to run parallel applications out of the box, with the
tools that work best (for them).

> (3) encourage people to provide packages for both MPICH2 and OpenMPI
>     (where possible, or only MPICH2 if OpenMPI not possible).

There currently is no easy way to do that easily, the burdon is on the
maintainers side. We can (and should!) encourage them, but we have to
accept that not everyone wants that. I'd personally would build only
against mpi-defaults-dev, for the reason that the user gets a working
application by installing the -mpi package, without the need to know
which of the (conflicting) MPI packages to choose[*]. On the other hand,
it would be a shame if users prefering MPICH2 would have to build all
packages by hand. But I do not see an easy technical solution to that so
we can ease the building of multiple MPI packages (semi-)automatically.
I'm happy for all ideas on that, though.

Best regards, and sorry for the long mail!
Manuel

[*] I'm aware of the fact that MPI users usually know about things like
that but since multi-core machines get more and more frequent, we need
to support the less clueful users at some point.



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Drew Parsons]

On Wed, 2009-12-02 at 00:48 +0100, Manuel Prinz wrote:

> Am Dienstag, den 01.12.2009, 21:20 +0100 schrieb Lucas Nussbaum:
> > While I would be fine with that, there are other possible plans:
> > (2) use MPICH2 as default everywhere (it is supported on all release
> >     archs). Clearly, the package didn't receive a lot of testing yet,
> >     but this is likely to be only a temporary problem.
>
> I do not care that much. We chose Open MPI because it was the most
> mature implementation at that time. I do not know much about MPICH2, and
> am open to use MPICH2 as the default. I'd like to go with Open MPI, but
> as one of the Open MPI maintainers in Debian, my view is biased.

As a data point from the "real world", the Australian Supercomputing
Facility currently offers Open MPI but not MPICH2 [1].  Mind you the
clusters are just x86_64 so no arcane architecture.

They will install new software if users request and justify the need, so
they might potentially build MPICH2 if someone asked, though I imagine
they'd first strongly encourage the user to try Open MPI first.

[1]
http://nf.nci.org.au/facilities/software/software.php?software=MPI&site=ANU&from_site=ANU




--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Drew Parsons]

On Tue, 2009-12-01 at 11:31 +0100, Manuel Prinz wrote:

> Am Montag, den 30.11.2009, 22:11 -0800 schrieb Nicholas Breen:
> > On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
> > > From the point of view of a client package, what is now best practice
> > > for working with MPI?  Is there a website/wiki/document explaining how
> > > to set up an MPI-using package, or is it just a matter of RTFM from
> > > mpi-default-dev?
> > >
> >
> > No particular documentation that I'm aware of, though it's a good thought....
>
> But adding MPI support is usually as easy as Nicholas pointed out in his
> email. If one only wants to build an MPI version, build-depending on
> mpi-default-dev is best; if you want to build one package per MPI
> implementation, you have to do that yourself. Nicholas' gromacs package
> is a good example for that!
>

I'll probably keep it simple and just build once against
mpi-default-dev.  If users have a strong need for other MPIs then they
can file a bug request.

Thanks all for the tips, hopefully won't be too tricky to get gerris
mpi-packaged.

Drew



--
To UNSUBSCRIBE, email to debian-science-request@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...