[gentoo-dev] vitrual/mpi

[gentoo-dev] vitrual/mpi

[Anton Starikov]

What about adding one more virtual?

There is couple ebuilds can provide MPI functionality (LAM and MPICH).
So, probably it is not so bad idea to add virtual.

Anton.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] vitrual/mpi

[Mike Doty]

good idea, has my vote for what it's worth

On Mon, 30 Aug 2004 23:05:59 +0200, Anton Starikov <antst@ifm.liu.se> wrote:
> What about adding one more virtual?
> 
> There is couple ebuilds can provide MPI functionality (LAM and MPICH).
> So, probably it is not so bad idea to add virtual.
> 
> Anton.
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] vitrual/mpi

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On Mon, 30 Aug 2004 23:05:59 +0200 Anton Starikov <antst@ifm.liu.se>
wrote:
| What about adding one more virtual?
| 
| There is couple ebuilds can provide MPI functionality (LAM and MPICH).
| So, probably it is not so bad idea to add virtual.

What needs it?

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] vitrual/mpi

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

On Monday 30 August 2004 05:05 pm, Anton Starikov wrote:
> There is couple ebuilds can provide MPI functionality (LAM and MPICH).

i dont know anything about MPI ... are there other packages which would DEPEND 
on this ?
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 838 bytes --]

Re: [gentoo-dev] vitrual/mpi

[Anton Starikov]

Ciaran McCreesh wrote:
> On Mon, 30 Aug 2004 23:05:59 +0200 Anton Starikov <antst@ifm.liu.se>
> wrote:
> | What about adding one more virtual?
> | 
> | There is couple ebuilds can provide MPI functionality (LAM and MPICH).
> | So, probably it is not so bad idea to add virtual.
> 
> What needs it?

for example:

app-sci/gromacs
app-sci/tree-puzzle
app-sci/octave
app-sci/orsa

I think that  not all. It just fast grep in app-sci.
Now these ebuilds use LAM-MPI by default. MPICH is out of the game.

Moreover, now I'm preparing ebuilds for blacs and scalapack. They will 
require mpi also.

Anton Starikov.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] vitrual/mpi

[Ferris McCormick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 30 Aug 2004, Mike Frysinger wrote:

> On Monday 30 August 2004 05:05 pm, Anton Starikov wrote:
> > There is couple ebuilds can provide MPI functionality (LAM and MPICH).
> 
> i dont know anything about MPI ... are there other packages which would DEPEND 
> on this ?
> -mike
>
Sorry to come in on the end of this without knowing the context.  If
everything that follows is irrelevant to the question, just ignore.

Both sys-cluster/lam-mpi and sys-cluster/mpich provide implementations
of mpi (message passing interface, I believe) to allow building
computation clusters, similar to PVM (parallel virtual machine).
Unfortunately, lam-mpi and mpich are not quite compatible.  A
few packages (few = 2 to 5) depend explicitly on lam-mpi in case
of USE='mpi ...', and apparently cannot use mpich. (dev-libs/fftw-2.x 
series, app-sci/gromacs, app-sci/orsa, app-sci/tree-puzzle)

- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBNSBVQa6M3+I///cRAlXlAJ9Q2OsoVtoBLFRNuLbKlOEtcNp/oACggjXy
J9Zswx86IA6pGQIyaUucNyU=
=+CCz
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] vitrual/mpi

[Anton Starikov]

Ferris McCormick wrote:
> Both sys-cluster/lam-mpi and sys-cluster/mpich provide implementations
> of mpi (message passing interface, I believe) to allow building
> computation clusters, similar to PVM (parallel virtual machine).
That's correct :) But MPI can be used not only with clusters. I have it 
on my home and office desktops, just because I develop software for MPI 
:) And people use it on SMP machines also.

> Unfortunately, lam-mpi and mpich are not quite compatible.  A
> few packages (few = 2 to 5) depend explicitly on lam-mpi in case
> of USE='mpi ...', and apparently cannot use mpich. (dev-libs/fftw-2.x 
> series, app-sci/gromacs, app-sci/orsa, app-sci/tree-puzzle)
That's right, these packages depend on lam-mpi, because it is hardcoded 
into ebuilds. One of ideas behind virtual/mpi is to make it possible to 
write ebuild that will support both of them. It is not impossible. 
Theoretically, any application, which can be compiled with LAM can be 
also compiled with MPICH, if application conform MPI standards (at least 
MPI 1.2) and not tuned especially for particular MPI realization (it is 
really exotic case, because it brokes one of ideas behind of  MPI as a 
open standard). So, on a source level (source of application which use 
MPI, of course) - they are the same.
There is only some minor difference about linking. And some exotic in 
case of using some non-standard Fortran features and MPICH. (for ex. if 
you get command-line arguments from Fortran, AFAIK it is not standard 
and not conform MPI standard, with MPICH you will get a bit more, than 
you need, and different on slave and master nodes :)). But AFAIR there 
no any exotic with C/C++.
But linking also could be done without problems. Ebuilds just should 
follow MPI standard and use mpicc instead gcc, mpif77 instead g77 and so 
on. If in ebuilds for LAM_MPI, MPICH (and something else which will 
appeared) it is properly configured, they will install such wrappers, 
which BTW cares about proper linking with proper libraries. AFAIR they 
do it now.
OK, often people really don't care about wrappers and link directly, 
that's true :) But even in such case there is no big problem with 
linking. Just add check in ebuild, which MPI we use. Or, probably in 
some applications autoconf care about it (I think in app-sci/gromacs 
such case).

fftw definetely  can use MPICH. Moreover, MPICH is much more spread than 
LAM, so, I almost sure that it is much more probable to find some 
software which will not work with LAM, rather with MPICH. For example, I 
always test my programs with MPICH, even if I personaly like LAM. So, I 
always keep one machine with MPICH. Because MPICH is some kind of 
portable reference implementation of MPI related to MPI standard developers.

-- 
Anton Starikov

--
gentoo-dev@gentoo.org mailing list